Qt Creator: Change working direktory for multiple run configurations or configure default

hs_bx

In Qt Creator, is there a way to change the working directory for multiple (or all) run configurations in the current project at once?

Alternatively, is there a way to configure a default working directory when opening a project?

I have a cmake project with ~20 executables / Run configurations. The working directory defaults to the binaries parent directory (within the build directory). However, I need the working directory to be the source tree / the projects root folder. With 3 kits that is ~60 working directories I would need to change, or is there an easier way?

Christian Ehrlicher

@hs_bx said in Qt Creator: Change working direktory for multiple run configurations or configure default:

I need the working directory to be the source tree

You should maybe fix this requirement.

hs_bx

@Christian-Ehrlicher said in Qt Creator: Change working direktory for multiple run configurations or configure default:

@hs_bx said in Qt Creator: Change working direktory for multiple run configurations or configure default:

I need the working directory to be the source tree

You should maybe fix this requirement.

It's not in my hands.

Also, I would agree in general. However, I'm not sure what a good alternative to using the working directory in that case would be. There are assets in the source tree (pictures, fonts, media files). Many of the projects binaries (= run configurations) operate on those files.

Using a user-wide config file (e.g. ~/.config/foo/bar.cfg) does not work for multiple source trees.
Copying the assets to the build directory wastes disk space, especially when switching compilers and release modes.
Symlinks don't work on Windows (as far as I know)
Setting the data directory as command line parameter would still require me to update all Run Configurations.

jsulm

@hs_bx said in Qt Creator: Change working direktory for multiple run configurations or configure default:

There are assets in the source tree (pictures, fonts, media files)

Those are usually handled as resource files which then are embedded into the executable. You can also have stand alone resource files not built into the executable. In both cases there is no need to copy anything to the build folder.
See https://doc.qt.io/qt-6/resources.html

JonB

@hs_bx said in Qt Creator: Change working direktory for multiple run configurations or configure default:

I need the working directory to be the source tree

When you release your application to other users there won't even be a "source tree" or directory, so it is not a good choice/undefined. If the user launches your application from the command line/terminal the current directory will be wherever they happen to be when they enter the command, which could be anywhere; if it is launched from some kind of "icon/shortcut" you are at the mercy of the OS/desktop manager for where the current directory, which may not be easy to control.

You should consider one of three ways:

Per @jsulm you could embed your support/asset files into your executable using Qt's resource system.
In your code you can use QString QCoreApplication::applicationDirPath() to discover the directory where the executable resides. Place/install your asset files somewhere relative to this (be that somewhere/ or ../somewhere/). You can also code this to allow as an alternative somewhere you like for design/development time for convenience, which will be sought first before falling back to where it will be in release/production.
Use one of the "special folder" locations in QStandardPaths Class and place your asset/support files there.

For development-time convenience you can always use, say, an environment variable/command-line parameter/configuration file/special code to locate the assets somewhere else. I do not know what your issues with "a user-wide config file" or "Setting the data directory as command line parameter" are, presumably you use the same assets location no matter which kind of build configuration you make. If you have "multiple source trees" (different applications?) I don't see a problem in adjusting those accordingly.

Of course it's up to you, and you'll probably ignore this. If you intend to release your application to other users I think you will find you come to grief if you leave it at requiring "current directory" at invocation time to work.

hs_bx

@jsulm said in Qt Creator: Change working direktory for multiple run configurations or configure default:

@hs_bx said in Qt Creator: Change working direktory for multiple run configurations or configure default:

There are assets in the source tree (pictures, fonts, media files)

Those are usually handled as resource files which then are embedded into the executable. You can also have stand alone resource files not built into the executable. In both cases there is no need to copy anything to the build folder.
See https://doc.qt.io/qt-6/resources.html

I'm using Qt Creator as IDE in a non-Qt-Project for game development, that's why the assets are not baked into the executable.

hs_bx

@JonB For release the assets are packaged differently. Also most of those binaries are just development tools that will never be released. The few binaries that get released can have special handling, but also the launcher (e.g. steam) and/or a wrapper will ensure a properly configured working directory.

This questions is purely about the developer setup.

Regarding multiple source trees: Sometimes its necessary or convenient to have multiple checkouts of the same Repo to compare different versions (including asset versions), a user-wide config file would interfere with that.

JonB

@hs_bx said in Qt Creator: Change working direktory for multiple run configurations or configure default:

a user-wide config file would interfere with that

You would make your configuration file take care of that situation, e.g. different sections for different versions or whatever.

Anyway whatever we say you wish to persist with relying on the current directory, so good luck.

hs_bx

Ok, I guess there is no way to do this currently. It's not that I disagree with any suggestions in principle, it's just that everything has tradeoffs.

So far, the best options for my unusual use case seem to be:

continue changing individual Run Configurations (or find a way to script these changes)
use a project wide environment variable
make a feature request (e.g. parameterized option "Default working directory" like "Default build directory", with stuff like %{Example:Build:BinaryDirectory}, %{Example:Build:Root}, %{Project:Path})

I guess most use cases wont benefit from such a feature, so I don't think a feature request will be successful. So I will probably use a project wide environment variable. Thanks for all suggestions and the discussion.

Christian Ehrlicher

Not using resources or absolute paths will hurt you sooner or later.

hs_bx

@Christian-Ehrlicher I'm convinced you're right for most use cases and applications. I also agree that relying on the working directory causes some hurt.

But, I'm dealing with a game with hundreds of megabytes of assets. Baking this stuff into the executable would increase build times, even doing asset-pack files during dev-builds would slow things down. -> More Hurt.

Regarding absolute paths: Maybe I'm missing something, what problem do you see with a project wide environment variable for my use case?

Sometimes I have to compare two different checkouts of the same code base, so I have two project directories of the same code base at different commits (including assets) and build-A-GCC-Release/bin/foo needs assets from A/... and build-B-clang-Debug/bin/foo needs assets from B/...). So hardcoding paths or using defines or even having user wide configs (e.g. ~/.config/...).