Which variables are you talking about. The ones in the CMakeLists truely look obsolete, since gecode is already added via the dependency moreorg (see the associated pc file)

GECODE_LIBRARIES was used but never set, but you are right, moreorg does provide includes and libraries, so i just removed that variable.

@2maz you want to review and merge this?

@pierrewillenbrockdfki do you have a buildconf that you use for testing? I encountered several issues while building. Also templ-gui does not run, and requires gecode's gist.h to be excluded - since that requires qt4 still.

@pierrewillenbrockdfki do you have a buildconf that you use for testing? I encountered several issues while building. Also templ-gui does not run, and requires gecode's gist.h to be excluded - since that requires qt4 still.

A buildconf is being worked on. I suspect the feature/qt5 branch of https://github.com/rock-core/rock-package_set helps already.

@pierrewillenbrockdfki do you have a buildconf that you use for testing? I encountered several issues while building. Also templ-gui does not run, and requires gecode's gist.h to be excluded - since that requires qt4 still.

A buildconf is being worked on. I suspect the feature/qt5 branch of https://github.com/rock-core/rock-package_set helps already.

Turns out gecode will pick qt4 over qt5 if given a choice, so some more changes will be required in rock-core/rock-package_set.

We should try first with Gecode's release/6.3.0 branch - it comes with a few updates on the Qt side.

We should try first with Gecode's release/6.3.0 branch - it comes with a few updates on the Qt side.

If you want to try that, there is a gecode-6.3.0 branch in https://github.com/pierrewillenbrockdfki/rock_core_rock_package_set.git (alongside a feature/qt5 branch that contains an attempt to have gecode compile against qt5 in the presence of qt4)

gecode-6.3.0 also is preferred on gentoo since 6.2.0 does have some trouble compiling with newer compilers.

I cannot really tell if it works right, though. It looks like there is only planning/templ => knowledge_reasoning/moreorg => tools/gecode in terms of users, so maybe you can take a look?

@2maz , did you have a chance to look at this again?

I did now run the integration tests for knowledge_reasoning/moreorg and planning/templ against gecode 6.3.0 and both pass, so i will go ahead and prepare the update to gecode 6.3.0 and split the patches for that out of this PR.

@2maz, i did the merge of the compile fixes to main, i don't think those can harm things. the update to gecode 6.3.0 is pending in rock-core/rock-package_set. the qt5 changes there will have to wait a bit until the gecode update lands.

@pierrewillenbrockdfki without being too strict and enforcing it, we should try to make a relevant Github CI pipeline run and succeed before a merge to main - so rather create/work with a feature branch on the repo.
As basis https://github.com/rock-planning/planning-templ/blob/main/Dockerfile exists along with the workflow definition.
However, a buildconf for testing the qt5 stuff and/or listing of PR dependencies is still required, e.g., I currently just have to assume that graph_analysis feature/qt5 should also be used?

For a merge request against 'main' you should also grant a bit longer response time window.

@pierrewillenbrockdfki adapted the Docker-based CI setup so that:

• buildconf is now picked from https://github.com/rock-planning/planning-templ-buildconf (same branch if it exists or 'main' otherwise) - there were additional fixes to graph_analysis (missing dep on qt5-svg, so updated feature/qt5 branch) and gui/osg_qt5 needed
• changed build default to ubuntu 20.04 - there seem to be incompatible changes for ubuntu 18.04 in gui/vizkit3d (feature/qt5) for finding and using boost libraries