Gate & Geant4: how to pass the variables from one port to the other

Mojca Miklavec mojca at
Sun Jul 7 05:15:45 PDT 2013

On Sun, Jul 7, 2013 at 9:00 AM, Ryan Schmidt wrote:
> On Jul 6, 2013, at 19:25, Mojca Miklavec wrote:
>> Let's say that Gate can depend either
>> on Geant4 9.5 or on 9.6 and that I decide to provide two port
>> variants, geant495 and geant496.
>> In case of dependence on 9.6 I need to provide the following:
>> variant geant496 conflicts geant495 description {Use Geant4 9.6} {
>>    depends_lib port:geant4.9.6
>>    configure.args-append
>> -DGeant4_DIR=${prefix}/lib/Geant4/Geant4.9.6/Geant4-9.6.2
>>    # 9.6.2 stands for "version 9.6, patch 2"
>> }
>> If/when patch 3 for Geant4 9.6 comes out, the second argument would
>> need to change into
>>    configure.args-append
>> -DGeant4_DIR=${prefix}/lib/Geant4/Geant4.9.6/Geant4-9.6.3
>> and Gate would need to be rebuilt anyway.
>> In case of dependence on 9.5, I would need:
>> variant geant495 conflicts geant496 description {Use Geant4 9.5} {
>>   depends_lib port:geant4.9.5
>>    configure.args-append
>> -DGeant4_DIR=${prefix}/lib/Geant4/Geant4.9.5/Geant4-9.5.2
>> }
>> Even though I can hardcode the value of Geant4_DIR in Gate, it is
>> probably cleaner/safer if the value would come from the Geant4
>> PortGroup, but then again I'm not sure how to handle the version
>> numbers. (The value comes from
>> -DCMAKE_INSTALL_LIBDIR=lib/Geant4/Geant${simpleversion} in the Geant4
>> port - simpleversion is set to "4.9.6" in the Geant's Portfile and
>> "Geant4-9.6.2" is added automatically by the installation scripts.)
>> What solution would you suggest for this? Supporting two versions of
>> Geant4 for Gate is not really required, but I still need to get the
>> variable for Geant4_DIR from somewhere (unless it's ok to hardcode
>> that value.)
> The Gate port should ask the installed geant4.9.6 software what its directory is. Depending on how geant provides this information, that might happen via pkg-config, a config script, a config file, or manual inspection of the directories that got installed.

Currently geant4.9.6 doesn't provide the information in any way, or at
least not that I know of (that is: no pkg-config, config file) unless
I create such a file as part of installation process.

By inspection of installed files I could use the equivalent of

> port contents geant4.9.6 | grep Geant4Config.cmake

but ideally I would like to set a variable like
    set geant.cmakeconfigdir = \
inside the Geant4.9.6 Portfile or portgroup.

What I don't know is:

1.) Whether it is possible to access the value of such a variable
(during configuration of Gate) without writing out special
configuration files during installation of Geant4.9.6. The easy way
would be to place that variable in the portgroup, but I don't know if
it is considered a good practice to put variables including patch
numbers into portgroups.

2.) Assuming that patchnumber goes away entirely. How should I define
the variable then? Something like the following?

    variant geant496 conflicts geant495 description {Use Geant4 9.6} {
        set geant.version 9.6
        # if needed
        # set geant.patchlevel 2
    variant geant495 conflicts geant496 description {Use Geant4 9.5} {
        set geant.version 9.5
        # if needed
        # set geant.patchlevel 2
    # make sure that at least one variant is selected
    # ...
    depends_lib port:geant4.${geant.version}
-DGeant4_DIR=geant.getcmakepath(geant.version[, geant.pathlevel])
    # getcmakepath from portgroup should then return
    # ${prefix}/lib/Geant4/Geant4.${geant.version}/Geant4-${geant.version}.${geant.patchlevel}

If this sounds reasonable, I would need a tiny bit of help defining
the function getcmakepath the the portgroup. (Tcl is a funny

> If it's complicated to find this out, then a proc in the portgroup would be a good idea so that the complicated bits are hidden out of the way.

If it is too complicated, I will just hardcode the value in the Gate
port and be done with it.

> Or, geant4.x should always install its software in the same directory, i.e. don't include the patchlevel in the directory name. Deciding whether to use this strategy might depend on how geant is usually packaged, and why they want the patchlevel in the directory name in the first place.

I don't know why they want the patchlevel. I can imagine that it can
be very useful for side-by-side installations of different versions,
in particular for developers who need to test multiple versions at
once. But given that the current scheme doesn't support multiple
versions of libraries (Geant4 9.5, 9.6, 10.0 would all install their
libraries into $prefix/lib/Geant4/libsomething.dylib, so libraries
would clash with each other, and if one tries to relocate the
libraries, CMake configuration folders are relocated as well), it
doesn't bring any benefit at all.

I can ask them why patchlevel is included. And I can try to simply
rename the directory during post-destroot phase to omit the
patchlevel. But I still need a way to specify the path somewhere: be
it by hardcoding it in Gate or by providing a function in the

Thank you,

More information about the macports-dev mailing list