Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Qt Creator and other tools
  4. Set run environment from script in QtCreator
Forum Updated to NodeBB v4.3 + New Features

Set run environment from script in QtCreator

Scheduled Pinned Locked Moved Unsolved Qt Creator and other tools
4 Posts 4 Posters 2.5k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • R Offline
    R Offline
    rmoyen
    wrote on 1 Aug 2017, 16:09 last edited by
    #1

    Hi,

    Is there a way to have a shell script automatically sourced to set the run environment in QtCreator (4.3.0, if that matters -- and on Linux obviously)?

    My projects use CMake and at one step it generates a bash script with a lot of environment variables. This script is specific to each project, and its content may change depending on some of the options that are passed to CMake (such as which modules are to be included in the project and so on), so I cannot simply edit my user environment. The normal way to start the program (i.e. not through QtCreator) is to call another script that first source this one to set the variables and then launches the executable.

    At the moment, whenever that file changes, I have to go to the run environment and use the "Batch Edit..." option, then copy-paste the content of the file in there. This is obviously not ideal, I sometime forget that the script has changed and get weird results in my application because of that... Plus, any copy-paste is a source of potential errors!

    So, is there a way I could tell QtCreator to automatically source that script before running the application, instead of doing that manually?

    I know that I can set a custom executable as the run target (i.e. the script that source the environment script + launches the true executable), but doing so means that e.g. starting the debugger directly doesn't work as it tries to debug the script and not the executable!

    I've also found another question that seems exactly identical to what I want to do, but it is from 2015 and hasn't got a single answer, so hopefully someone will have an idea now?

    Thanks!

    1 Reply Last reply
    1
    • D Offline
      D Offline
      David Warren
      wrote on 6 Jun 2018, 21:19 last edited by
      #2

      @rmoyen , Did you ever find a solution to your problem? I having exactly the same issue on Ubuntu and would really like to know if there is a good answer for it.

      A 1 Reply Last reply 7 Jun 2018, 19:45
      0
      • D David Warren
        6 Jun 2018, 21:19

        @rmoyen , Did you ever find a solution to your problem? I having exactly the same issue on Ubuntu and would really like to know if there is a good answer for it.

        A Offline
        A Offline
        aha_1980
        Lifetime Qt Champion
        wrote on 7 Jun 2018, 19:45 last edited by
        #3

        @David-Warren

        I'm not aware that would be possible, beside the mentioned custom executable.

        Regards

        Qt has to stay free or it will die.

        1 Reply Last reply
        1
        • D Offline
          D Offline
          Didier Weckmann
          wrote on 2 Dec 2019, 11:29 last edited by
          #4

          I have exactly the same problem here, but on macOS. We use conan to bundle our dependent libraries (VTK, opencv, ...) and obviously each libraries have an independent path which is, of course, not /usr/lib. This require us to set DYLD_FALLBACK_LIBRARY_PATH for each library to allow the executable to run (using linker RPATH is not an option since conan libraries can be installed virtually anywhere). Our cmake generate the correct script that set the variable for us, but we fall in the described problem here, as, even if setting a custom executable allow us to launch the application, we cannot debug it since the debugger seems to attach to the shell that execute the script rather than the launched application. Setting DYLD_FALLBACK_LIBRARY_PATH as an environment modifier inside the run environment is not doable because the run environment is the same for debug and release build (and the dependent libraries are not, so different paths !). Furthermore, it is just really painful to set it for all dependent libraries...

          So if someone have a solution to attach the debugger to a custom executable that is a script, or to use an external script to generate the run environment, we will be glad ;)

          1 Reply Last reply
          0

          • Login

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved