Remaken install with conditions actually performs configuration

[jim-bcom]

HOW TO REPRODUCE

• take a packagedependencies.txt file with a condition, say %COND
• invoke remaken install --condition COND=true/remaken install + yes via the command line

EXPECTED BEHAVIOR

• installs the depedency if true, don't install it if false but do no configure project

OBSERVED BEHAVIOR

• creates file .build-rules/linux-gcc-x86_64/configure_conditions.pri

DEFINES += COND

• In the documentation, configure and install are two separate commands, so I would expect conditions on install to only perform an installation of the conditionnalized dependency.
• We encounter this behavior wtih our CI where remaken install is called so that it always answer yes to everything (because there might be other cases where the command prompts the user for input other than remaken conditions). But then, when building the actual qmake project, we define variables to set the expected conditions in the .pro file. But since the configure_conditions.pri is already generated with all conditions to true, it seems that what we set the the .pro file is not taken into account.

[stefled]

remaken install command creates .build-rules/[os]-[build-toolchain]-[architecture]/configure_conditions.pri file as described in remaken documentation

configure and install are two separated command for installing dependencies :

• install is the current way for finding dependencies. This command uses specific include/links dependency paths (.pc, system, conan generated files).
• configure is not used currently in projects. This command changes the way of finding dependencies, by generating .pri files with all include/links dependency paths. it's a static search of dependency that change the 'qmake' execution on projects,

You can add a configure_conditions.pri in the project root folder, or a [--condition name=value] command line parameter of remaken, for set condition without prompt.

[jim-bcom]

• OK, so remaken install should not be used outside of a project. I thought of it as similar to conan install, but clearly it expects to be called in a project directory if it generates such meta data, am I correct? It was sometimes convenient to write a packagedependencies.txt only to remaken install some deps in the remaken cache, though. I don't know if it makes sense to you to have such a feature, like for exemple by adding a --install-only option, I don't know...
• I use configure_conditions.pri locally to set my conditions. It's a convenience to not have to be prompted when I build all my projects. But to me, I considered it as something not to put in version control, as it is more a per-user config. I don't want to force the condition I use to other users that can have other needs for the project. That's why I added this file in the .gitignore files, in order to avoid having this file changed all the time.
• For now I guess we could use the configure_conditions.pri approach for our CI issue. As I said, currently the option was expected to be hard coded in the .pro anyway, so this is as good(bad?) as it was. But ideally, to me, we should not commit such a file, and we'd need some work on our side to be able to pass the condition to our CI without this file (via the JenkinFile for example).

[stefled]

OK, so remaken install should not be used outside of a project. I thought of it as similar to conan install, but clearly it expects to be called in a project directory if it generates such meta data, am I correct? It was sometimes convenient to write a packagedependencies.txt only to remaken install some deps in the remaken cache, though. I don't know if it makes sense to you to have such a feature, like for exemple by adding a --install-only option, I don't know...

Remaken commands are originally designed to be called within a project, but they're generic enough to be called outside of it.
To manage only the installation of dependencies written in a packagedependencies.txt file, the --shared-only option has been added. Does it meet your needs for your --install-only option?

I use configure_conditions.pri locally to set my conditions. It's a convenience to not have to be prompted when I build all my projects. But to me, I considered it as something not to put in version control, as it is more a per-user config. I don't want to force the condition I use to other users that can have other needs for the project. That's why I added this file in the .gitignore files, in order to avoid having this file changed all the time.

For now I guess we could use the configure_conditions.pri approach for our CI issue. As I said, currently the option was expected to be hard coded in the .pro anyway, so this is as good(bad?) as it was. But ideally, to me, we should not commit such a file, and we'd need some work on our side to be able to pass the condition to our CI without this file (via the JenkinFile for example).

When conditions are used in remaken install/configure, it overloads conditions written in the configure_conditions.pri, then developper is in the good condition context for the project. Then conditions could not be hard coded in the .pro. Perhaps it's required CI scripts modification in order to take this behaviour in account only for some projects.