Flavor qt5

[pierrewillenbrockdfki]

There are now considerable numbers of feature/qt5 branches floating around, but it turns out that having rock packages that try to support both qt4 and qt5 versions at the same time is problematic.

• Their manifest.xml cannot express the "at least one of" qt4 or qt5 libraries needed.
• The package cannot require the qt4/qt5 version of another rock package, and the other rock package cannot have both a qt4 and qt5 version installed.
• The package needs to know if it is supposed to build qt4 or qt5 version of its libraries(granted, this can be done easily), at the same time adjusting its dependencies for the selected variant.
• At least for the packages, it would be beneficial to not have to use branches to distinguish between the two variants, keeping common code the same and only having to use ifdef or different source files for the qt bits.

Since this is basically creating a new fork of rock, maybe that could be selected through the existing flavor system(a configuration would probably work, too).

For the osdeps, the qt4 osdeps would be moved to a rock.osdeps-qt4 file, the qt5 osdeps would be added to rock.osdeps-qt5 and the workspace variable osdep_suffixes would be setup accord to the flavor. The qt osdeps would be used without a version marker, making it impossible to mix qt4 and qt5 in the same rock installation, and allowing the packages manifest.xml to properly reference the qt osdeps. Packages that do not support qt4 or qt5 would be conditionally added to the relevant flavor(s).

I want to add that there is also a possible solution that involves teaching autoproj to work with gentoo-style use-flags, that is, options to packages that determine what they build, that the packages can use to conditionally depend on osdeps and other packages, and that the packages can require from other packages. If you think this would mean an explosion in the search space for package combinations, you'd be right.

Please discuss.

@doudou @planthaber @annaborn

[doudou]

Right. One remark I have is that since the ruby toolchain still depends on Qt4, this truly creates a fork of the rock toolchain. The C++ based toolchain and the ruby-based one. This is the hard point. The whole Qt4/Qt5 thing is not an issue for e.g. standalone programs that use one or the other - those can (and already do) coexist. The issue is essentially vizkit/vizkit3d.

Well, I guess, it does not actually create a fork, it just makes its existence more obvious.

Another points to fuel the discussion:

• I really want to get rid of the flavor system. It's very heavy, and we don't use it anymore for the rock flavors (since master has essentially been the only usable rock flavor for years).
• we can and do have a mixed Qt5/Qt4 environment - the only thing we can't have is qt4/qt5 in the same process. A.k.a. We should not forbid having qt5 and qt4 dependencies in the same system.

The overall design philosophy behind autoproj is to give low level tools, but try to not put its hands in heavy-handed enforcing of constraints. That's have generally been the job of the autobuild files. So, something that would allow us to achieve the same result would be:

• have a configuration flag (do you want the C++ or Ruby toolchain ?)
• change autoproj to allow for a conditional enabled/disable of dependencies in manifests (e.g. <depend package="..." if="..." />)
• pass the 'right' CMake defines in autobuild files based on this flag when applicable

[pierrewillenbrockdfki]

Right. One remark I have is that since the ruby toolchain still depends on Qt4, this truly creates a fork of the rock toolchain. The C++ based toolchain and the ruby-based one. This is the hard point. The whole Qt4/Qt5 thing is not an issue for e.g. standalone programs that use one or the other - those can (and already do) coexist. The issue is essentially vizkit/vizkit3d.

Being pedantic, the GUI parts of the ruby toolchain don't work with Qt5, while the C++ based toolchain(s) do work with Qt4. The ruby tools and the C++ tools do cooperate (apart from certain tools that will not tolerate tasks they did not start themselves).

Well, I guess, it does not actually create a fork, it just makes its existence more obvious.

Another points to fuel the discussion:

* I really want to get rid of the flavor system. It's very heavy, and we don't use it anymore for the rock flavors (since master has essentially been the only usable rock flavor for years).

Okay, then i will leave the flavor system alone.

* we can and do have a mixed Qt5/Qt4 environment - the only thing we can't have is qt4/qt5 in the same process. A.k.a. We should not forbid having qt5 and qt4 dependencies in the same system.

I 100% support this. Not so much as a system that one would want to use, but rather something that should be possible.

The overall design philosophy behind autoproj is to give low level tools, but try to not put its hands in heavy-handed enforcing of constraints. That's have generally been the job of the autobuild files. So, something that would allow us to achieve the same result would be:

* have a configuration flag (do you want the C++ or Ruby toolchain ?)

So, enabling C++ would mean to prefer qt5 and ruby would mean to prefer qt4, while only vizkit itself will be missing in the C++ version(and a small number of tools depending on vizkit), while everything (including the c++ toolchain) is available in the ruby version. The widgets would work in both versions, but with the c++ toolchain you would have to use c++ tools. I am not sure if i would make the user decide along the lines of the toolchains. Either way, this configuration would need good documentation about its effects.

* change autoproj to allow for a conditional enabled/disable of dependencies in manifests (e.g. `<depend package="..." if="..." />`)

* pass the 'right' CMake defines in autobuild files based on this flag when applicable

This would put the onus of keeping the packages configuration sane on the package-sets. Which is fine, i think.

@doudou What do you think would be best suited for the "if" attribute of "depend"? Existing environment variable? Some kind of configuration flag system that can be set per package? a ruby expression?

[pierrewillenbrockdfki]

Autoproj has been changed to allow for dependencies in packages that can be conditional on configuration variables: https://github.com/rock-core/autoproj/pull/382 The solution proposed by this pull request will not be used. Instead, a configuration item will be added in another pull request, allowing to either use branches or have packages change their dependencies between qt4 and qt5 depending on that configuration item.