Message: Re: CMAKE_INSTALL_LIBDIR & proper way for side-by-side installation of multiple Geant4 versions Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

None Re: CMAKE_INSTALL_LIBDIR & proper way for side-by-side installation of multiple Geant4 versions 

Forum: Installation and Configuration
Re: Question CMAKE_INSTALL_LIBDIR & proper way for side-by-side installation of multiple Geant4 versions (Mojca Miklavec)
Re: Warning Re: CMAKE_INSTALL_LIBDIR & proper way for side-by-side installation of multiple Geant4 versions (Ben Morgan)
Re: None Re: CMAKE_INSTALL_LIBDIR & proper way for side-by-side installation of multiple Geant4 versions (Mojca Miklavec)
Date: 04 Jul, 2013
From: Ben Morgan <Ben Morgan>

On Thu, 04 Jul 2013 12:21:28 GMT, Mojca Miklavec wrote:
> On Thu, 04 Jul 2013 10:16:50 GMT, Ben Morgan wrote:
> 
> > 
> > We will certainly review the install paths and their configurability.
> > However, what is the use case for simultaneous multiple versions?
> 
> 1.) A physicists who wants to run simulations he/she wrote a year ago.
> 
> 2.) A physicists who wants to benchmark differences between different
> versions of Geant4.
> 
> 3.) Someone who wants to use Gate (which currently depends on Geant4
> 9.5) and still be able to write and run simple simulations with the
> latest version of Geant4 (maybe even 10.0)
> 
> 4.) Maintainer of MacPorts packages who doesn't need to constantly
> activate and deactivate different versions of Geant4 and packages
> depending on it (Gate) to test/fix/patch the other version.

To play devil's advocate for a minute on at least the first point - We encourage and recommend the use of the latest release, which fits with the MacPorts update philosophy. The libraries provide the requisite functionality to check the version at compile time and hence adapt the code to account for changes in API etc. Other issues preventing upgrades such as bugs need to be reported to us ASAP so we can create suitable patches.

Nevertheless, I understand your points - the issue in my mind is simplicity and avoiding clashes. Here a single install of the latest release covers both.

> > Macports provides the ability to activate/deactivate ports, and for a
> > library like Geant4 this would seem to be a much easier solution.
> 
> But activating/deactivating still takes a lot of time (particularly if
> talking about deactivating G4NDL) and starts to get annoying.

There shouldn't be a need to activate/deactivate datasets if these are separate ports.

> Even if one solution is a bit more difficult for the maintainer to
> implement, it only needs to be done once, and then all users can benefit
> from more user-friendliness.
> 
> (One thing I'm not aware of though, is whether such installation would
> make it more difficult for developers of Geant4-based simulations to
> find Geant4 and use the right flags for compiling.)

It shouldn't make it more difficult, other than to require the need to specify the Geant4_DIR variable. MacPorts CMake would I think automatically find the current Geant4 port install if you installed that with CMAKE_INSTALL_PREFIX set to the MacPorts root directory.

> > That's
> > especially true since later on you talk about making symlinks - in
> > essence you'll have to provide a whole "python_select" type layer to
> > choose the correct version.
> 
> Honestly (or should I say luckily?) I'm not yet aware of all the details
> that need to be fixed in order to be able to run a specific version of
> Geant4. In the current implementation I created three ports (9.5.p02,
> 9.6.p02, 10.0.b01), installed them in parallel without clashes, created
> a port for Gate 6.2 depending on Geant4 9.5, installed it, and it
> kind-of-works (many examples work, some crash). For that I didn't even
> have to install any symlink at all. All I had to do was to provide
> 
>     -DGeant4_DIR=${prefix}/lib/Geant4/Geant4.9.5/Geant4-9.5.2
> 
> and I believe that this should be
> 
>     -DGeant4_DIR=${prefix}/lib/Geant4-9.5.2

As I said, we can review the configurability of the installation paths, but this will always be done within the framework of standards compliance (i.e. no special cases - those you have to patch yourself). The only thing I can recommend at present is to do a (what I would call) "multiple qt on linux" style install. Here, you'd set CMAKE_INSTALL_PREFIX to ${prefix}/lib/Geant4-version. That gives you a common prefix, and isolates everything under one roof, which seems best for multiple versions.

> > The script will (or rather should ) cope with symlinks. The script is
> > intended to use relative paths from where it locates itself (physical
> > location, not symlink) to the relevant directories. That should handle
> > even highly customized paths - so please check what it actually outputs,
> > as if it doesn't handle this, there's probably a bug.
> 
> It doesn't. This works fine:
> 
>     > . /opt/local/libexec/Geant4/Geant4.9.5/geant4.sh 
>     > export
>     declare -x DYLD_LIBRARY_PATH="/opt/local/lib/Geant4/Geant4.9.5:/opt/local/lib/Geant4/Geant4.9.5"
>     declare -x PATH="/opt/local/libexec/Geant4/Geant4.9.5:/opt/local/libexec/Geant4/Geant4.9.5:/usr/texbin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin"
> 
> But this doesn't:
> 
>     > ln -s /opt/local/libexec/Geant4/Geant4.9.5/geant4.sh .
>     > . geant4.sh 
>     -bash: cd: /tmp/../../../lib/Geant4/Geant4.9.5: No such file or directory

O.k., my mistake, I was referring to geant4-config. The shell scripts for sourcing are awkward to handle for ensuring relocatability, but I'll see if the symlink resolution can be ported across.

Sourcing the geant4.(c)sh - ignoring data files for the moment - shouldn't be needed on Mac and especially Macports, because of the setting of the path and library install names.

Data paths are trickier - especially for supporting concurrent installs, where you might mess up the environment. There will be functionality in the 10.0 release that will get CMake and geant4-config to report the relevant data paths for the install, but this puts the onus on the application developer to write a wrapper to ensure the environment is configured correctly.

> > Nevertheless, I would not recommend trying to have concurrent installs
> > of multiple versions of Geant4 in MacPorts...
> 
> What are the main reasons against concurrent installs (apart from
> "slightly" more work for the maintainer of the package)? Would programs
> crash because of that? Does it become more difficult to develop own
> applications?

The main one is simplicity - Geant4 shouldn't be any different to any other C++ library. That is, the latest release is recommended and all that should be needed. The requirement to use older versions is down to individual applications, and as mentioned above, these are really special use cases - other than bugs, which we need to be informed about.

> PS: this is a test package which still needs quite some polishing -
> https://trac.macports.org/browser/users/mojca/ports/science/geant4.9.6/Portfile

Thanks! Please don't take any of my points as hard criticism of this - I think it's fantastic you're doing this work, and much appreciated! My concern is simply to provide high quality and robust installs following standard practices.

Cheers,

Ben.

Inline Depth:
 1 1
 All All
Outline Depth:
 1 1
 2 2
 All All
Add message: (add)

1 None: Re: CMAKE_INSTALL_LIBDIR & proper way for side-by-side installation of multiple Geant4 versions   (Mojca Miklavec - 04 Jul, 2013)
(_ Question: Re: CMAKE_INSTALL_LIBDIR & proper way for side-by-side installation of multiple Geant4 versions   (Mojca Miklavec - 25 Jul, 2013)
 Add Message Add Message
to: "Re: CMAKE_INSTALL_LIBDIR & proper way for side-by-side installation of multiple Geant4 versions"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews


[ Geant 4 Home | Geant 4 HyperNews | Search | Request New Forum | Feedback ]