Set link_directories for exported Geant4 target #3086
Conversation
| @@ -22,6 +22,13 @@ set_target_properties(geant4 | |||
| PROPERTIES INTERFACE_INCLUDE_DIRECTORIES | |||
| "${Geant4_INCLUDE_DIRS}") | |||
|
|
|||
| # TODO: fix upstream and provide proper variable for library directories | |||
| # for now derive from Geant 4 include dir (first in list) | |||
| list(GET Geant4_INCLUDE_DIRS 0 Geant4_INCLUDE_DIR) | |||
There was a problem hiding this comment.
for my education, is this fixing some problem?
There was a problem hiding this comment.
@sawenzel Yes, it ensures consistent usage of the settings as detected (and cached) by cmake. In other words, the build is then fully configured by cmake and does not require the Geant4 environment to compile. Together with alisw/alidist#2121 it also fixes recompilation from the BUILD directory without the aliBuild environment.
Do you see an issue with this?
There was a problem hiding this comment.
no. just wanted to understand the rational.
|
@gqp hum, this looks fragile to me... The very name lib for lib dir is assuming we're not targeting platforms/distributions which are using variants like lib64, etc.. Also, we're betting the relative path from include to lib won't change in Geant4... So, as rightfully stated in your own comment in the file it should ideally be handled upstream. @ihrivnac do you know if that's something that is considered already ? |
|
@aphecetche Thanks. Indeed, this is an ugly work-around for the fact that Geant 4 does not expose its library path. However, not setting this in FindGeant4 and relying on the linker to find a library somewhere (which is not even guaranteed to be the one corresponding to the include dir used) is simply broken. So, until fixed upstream, we will have to do some heuristics here. I will try and make it more robust with a call to find_library() on a suitable base directory. |
|
Hi, We are however still using 10.4.p2, and my PR for 10.5.p01 since last Friday (alisw/alidist#2114) is failing due to a problem on the test machine. |
|
@ihrivnac Ok, 10.6 indeed seems to address many of the cmake shortcomings. Is it planned to move to 10.6 anytime soon? If this is not imminent, I would still try to fix FindGeant4 for now. With the move to 10.6 FindGeant4 (and probably other pieces) would then have to be touched anyway, also to properly use the exported targets instead of the current usage of Geant4_INCLUDE_DIRS. |
|
If there are no objections from the simulation WP, we can move to 10.6; as by moving to 10.5 we will anyway go for a different version than the one used in production. |
|
I think we already discussed this and from my side we can go to 10.6. |
f21e8fe to
f3c0856
Compare
|
@aphecetche This should be more robust now and provide the required information (before the move to 10.6 happens). Let me know if you have further suggestions. |
|
@aphecetche Yes, to be revisited once we move to 10.6, I am available for this, of course. @ihrivnac Can you take care of the JIRA ticket or whatever it needs to get going with the upgrade to 10.6? You know the situation there much better than I do. Keep me in the loop, please. |
|
Ok, I will take care of the JIRA ticket. |
|
Issue is created https://alice.its.cern.ch/jira/browse/O2-1242 |
No description provided.