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)
Date: 04 Jul, 2013
From: Mojca Miklavec <Mojca Miklavec>

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.

> 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.

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.)

> 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

anyway. I just didn't figure it out how to "convince" the *.cmake files to be installed to ${prefix}/lib/Geant4-9.5.2 instead of ${prefix}/lib/Geant4/Geant4.9.5/Geant4-9.5.2, while keeping the *.dylib files at ${prefix}/lib/Geant4/Geant4.9.5.

If an equivalent of "python_select" needs to be implemented, I'm fine with it as long as I can get a bit of support and hints from the MacPorts (and Geant4) community.

> > Less important, but related:
> > 
> > I would also like to use $prefix/include/Geant4/Geant4.9.6 for included
> > files (CMAKE_INSTALL_INCLUDEDIR=include/Geant4/Geant4.9.6), but Geant4
> > would automatically add Geant4 to the end, so I end up with
> > $prefix/include/Geant4/Geant4.9.6/Geant4/include/G4Something.hh.
> 
> Yes, you will always get "Geant4" appended to the include dir path. We
> install a lot of headers, so they need to be "namespaced". We won't
> change this, but you can patch if your use case requires.

It's not really required. It would only be a bit nicer to have one level less, but it's also acceptable the way it is now.

> > DATAROOTDIR is also automatically suffixed with Geant4-9.6.2 (I don't
> > know if there is any way to control that).
> 
> As of 9.6, you should be able to set the CMake variable
> GEANT4_INSTALL_DATADIR variable to the path where data can be found.
> This is described in the Installation Guide.

No, that seems to be a different variable. I currently set both:

    -DGEANT4_INSTALL_DATADIR=${prefix}/share/Geant4/Data
    -DCMAKE_INSTALL_DATAROOTDIR=share/Geant4/Geant4.9.6

and that means that Geant4 will use data files from, say, ${prefix}/share/Geant4/Data/G4NDL4.3. But DATAROOTDIR is the location where *.gmk files fly (and possibly others). With the above settings I get the data files properly found, plus the following files:

    /opt/local/share/Geant4/Geant4.9.6/Geant4-9.6.2/geant4make/geant4make.csh
    /opt/local/share/Geant4/Geant4.9.6/Geant4-9.6.2/geant4make/geant4make.sh
    /opt/local/share/Geant4/Geant4.9.6/Geant4-9.6.2/geant4make/config
    /opt/local/share/Geant4/Geant4.9.6/Geant4-9.6.2/geant4make/config/analysis.gmk
    /opt/local/share/Geant4/Geant4.9.6/Geant4-9.6.2/geant4make/config/...
    /opt/local/share/Geant4/Geant4.9.6/Geant4-9.6.2/geant4make/config/sys/WIN32-VC.gmk
    /opt/local/share/Geant4/Geant4.9.6/Geant4-9.6.2/tools.license

I changed it to

    -DCMAKE_INSTALL_DATAROOTDIR=share/Geant4

now.

> > Related, more important, but a completely different issue:
> > 
> > I also had to set CMAKE_INSTALL_BINDIR=libexec/Geant4/Geant4.9.6 to be
> > able to avoid clashes, but since all the paths in geant4-config for
> > example are written in a relative way, I cannot simply make a symlink
> > like
> > 
> >     ln -s $prefix/libexec/Geant4/Geant4.9.6/geant-config $prefix/bin/
> > 
> > Of course I can patch geant-config, but it would be a lot better to have
> > some option to hardcode paths automatically. The installation (even
> > though default one, with some path changes) is not really rellocatable
> > anyway. 
> 
> 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

The script determines location of the symlink instead of its own location.

(Btw: is DYLD_LIBRARY_PATH really needed on a Mac? I'll try to experiment if programs work without that.)

> This is on the list of things to look at (use of rpath on mac) - but
> since (as far as I know) Macports installs are not intended to be
> relocatable

They definitely don't need to be and I wasn't asking for making it relocatable at this point. I was just stating that it's currently not relocatable. And if it's not relocatable, it could make sense to hardcode some paths if/when that's necessary, or maybe fix the scripts.

Again, I can fix/rewrite the scripts myself as part of installation process, but it would be great if it worked out-of-the-box.

> this shouldn't be an issue. In fact, you almost certainly
> want this as otherwise you have to fiddle with environment variables or
> fixup the library paths on the fly.

Actually, Mac OS X has this solved somehow. This is how most bundled applications (Something.app) work. They simply link to @executable_path/@rpath and the whole tree is free to move around ;)

Again: I'm not asking to change anything here. Just those three shell scripts, if possible. If not, I'll patch locally.

> 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?

I definitely wouldn't be doing it for the sake of my own local installation, but a bit extra effort for the sake of package manager is ok (as long as that doesn't mean less usability/more crashes etc.).

Mojca

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

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   (Ben Morgan - 04 Jul, 2013)
(_ 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 ]