[Rivet] Rivet issues with Genser libraries

[Andy Buckley]

Alberto Ribon wrote:

>   However, for a more general usage, as Rivet showed, these
>   scripts are not enough, and keep improving them seems to me
>   a difficult and likely too ambitious activity.

I'd agree with that! Like you, I think the existing scripts have done
very well, but that it's probably better to start again than try to
extend them forever.

>   Moving to a new system based on autoconf seems to me the
>   right thing to do at this stage, especially because we do
>   not need to start from scratch, taking advantage of the
>   experience, and assistence/help that you, Rivet developers,
>   are willing to give us.
> 
>   To be concrete, I would propose, as Witek already suggested, 
>   to start with the two main Fortran generators, Pythia and 
>   Herwig. If you can send us your building structure based on
>   autoconf for these two generators we can start to have a look
>   and to play with.

Absolutely - you can find them from our SVN area,
http://svn.hepforge.org/cedar/trunk/pub/contrib/

and also as tarballs from the CEDAR download area:
http://www.hepforge.org/downloads/cedar

[I'll probably remove these tarballs soon, since they aren't compatible
with the latest, greatest, soon-to-be-released Rivet (which expects the
Genser library names, dummy libs etc.]

>   Let's keep in touch,

Absolutely!


Now a few details about the autoconf problems, as I understand them. The
first unusual thing about the LCG installation, compared with generic
autotools installs, is the LCG "platform tag" which you need in the
installation prefix. Since we could also benefit from knowing the tag,
I've started to move Mikhail's "tag calculator" script from the Genser
makefiles into an autoconf macro (which isn't quite finished yet, but
should be working for the Rivet release --- next week, I hope). For
Genser installs, we could either let you set the prefix manually,
including the tag, or provide a --enable-lcg-install switch to configure
which would automatically insert the tag. Either way, I don't think it's
a blocker problem.

A more technical issue is the relocation of installed files. Relocation
isn't a particularly good idea where autoconf is involved, particularly
due to library paths which can be written into the binaries and .la
files by libtool. Better would be installation into
a versioned development area, with "dev" and "pro" symlinks pointed in
the usual way to the current development and production versions ---
that way no relocation-by-copying is needed and the libtool paths won't
break. If relocation is definitely needed, e.g. for Grid distribution of
generators, then I think that stripping the .la files may help, but this
would need closer investigation. The autopackage
(http://www.autopackage.org) system has interested me before
and it might be that we can use in some places and learn from it in others.

Are there any other autoconf concerns that I'm not aware of?

Andy