This was introduced with the "fix" for #1227 . All external projects using UseGeant4.cmake are now silently switched to use geant4-cxxflags (unless they re-add their own flags afterwards again). This is completely fatal: - All packaging systems are forcefully broken, their flags are just overridden silently. This effectively breaks packaging policy for all linux-distributions for all cmake-based packages compiling against geant4 (and using UseGeant4.cmake in the process). - A real-life and well-known example is geant-vmc: If I want to build it with "-std=c++11" (which is needed to compile against ROOT 6) and just configure that via ccmake / set CMAKE_CXX_FLAGS manually in the CMakeLists.txt, it is just silently overridden once UseGeant4.cmake is parsed when configuring for Geant4 => the flag is not applied and compilation against ROOT 6 fails. - Also, if I package geant-vmc for my distribution (Gentoo), the distributor-cflags are silently erased, breaking packaging-policy. An external cmake-macro should *never* replace *any* CMAKE_<LANG>_FLAGS. It is harmful enough that cmake even allows touching such variables from deeper scope. The "duplicate flags" issue described in #1227, however, is naturally harmless (one could also write a cmake-regexp to fix this, but I am not deep enough in this obscure syntax to offer a patch). As an intermediate fix I would suggest using the workaround described by the original reporter in #1227 . Thanks for your help and sorry if my tone was a bit rough (it really took me some time to track this down), Oliver
Two more comments on this: 1) > set(_tmp_CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${Geant4_CXX_FLAGS}") (from the original report) is actually also fatal, it should of course be set(_tmp_CMAKE_CXX_FLAGS "${Geant4_CXX_FLAGS} ${CMAKE_CXX_FLAGS}") to set the Geant-flags as base and allow to override them. As the standard-user will not add flags at all, or should only flags which he/she really needs, this is the best solution (e.g. geant-flags switch back from c++11 to c++98 again so I cannot switch there). 2) The documentation in the comments in UseGeant4.cmake clearly states that the user-set flags are only extended / Geant-flags are used as known-good base-flags (as I would expected and have described in 1) ).
Thanks for the report, and we'll fix this, but one comment/question: (In reply to comment #0) > - A real-life and well-known example is geant-vmc: If I want to build it with > "-std=c++11" (which is needed to compile against ROOT 6) and just configure > that via ccmake / set CMAKE_CXX_FLAGS manually in the CMakeLists.txt, it is > just silently overridden once UseGeant4.cmake is parsed when configuring for > Geant4 => the flag is not applied and compilation against ROOT 6 fails. > If I understand correctly here, the Geant4 being linked to is compiled against C++98, but geant-vmc is required to be compiled against C++11. If that's the case, and libstdc++ is being used then don't ABI incompatibility problems arise? That doesn't invalidate the bug, but I think we might need to be careful about "required" vs "recommended" flags (but I guess that in allowing CMAKE_CXX_FLAGS to take precedence it's the user's problem!).
(In reply to comment #2) > Thanks for the report, and we'll fix this, but one comment/question: Thanks! > If I understand correctly here, the Geant4 being linked to is compiled against > C++98, but geant-vmc is required to be compiled against C++11. If that's the > case, and libstdc++ is being used then don't ABI incompatibility problems > arise? In principle, yes - however, all projects linking against ROOT 6 will have to switch to C++11, they are now exposing C++11-only features in their headers. For that reason, also geant-vmc has to use -std=c++11 if compiled against ROOT 6. Luckily, this is not a very strong issue; in packaging, distributions will use the same compiler version for all packages, and also in larger setups / computing clusters, the compiler-version which one uses to compile all his / her code is very likely to be the same. With similar compiler-version, the ABI-incompatible changes between C++98 and C++11 are minimal (although present): https://gcc.gnu.org/wiki/Cxx11AbiCompatibility At the moment, I see no other solution than living with this risk (I am still alive after many days with a very "mixed" system ;-) ). > That doesn't invalidate the bug, but I think we might need to be careful about > "required" vs "recommended" flags (but I guess that in allowing CMAKE_CXX_FLAGS > to take precedence it's the user's problem!). Indeed ;-).
Fixed on trunk, tag will go into release 10.1. Backporting to earlier releases will happen with any further patches to those versions.
I can sadly still reproduce this even with 10.5.1 . Could you link the commit which should have fixed it?
This is now properly fixed on the git master, so will be in 10.6 due later this month. Apologies it's taken so long to resolve.
