[Rivet] rivet

Dmitri Konstantinov Dmitri.Konstantinov at cern.ch
Fri Apr 12 14:49:18 BST 2013


Hi Andy,

On 4/12/13 3:30 PM, Andy Buckley wrote:
> Can you explain to me what role cmake will play in the Rivet
> installation? You mean that you're using cmake to trigger the autotools
> build? We have a long-standing agreement that the MCnet generator build
> systems won't be modified without permission, and I can imagine endless
> problems if you guys are planning to rewrite the Rivet build scripts in
> cmake from now on.... I hope that's not what you meant!
Exactly, we just trigger the autotools build. No modifications/ no 
rewriting :)
>
>> So please note that new version of RIVET will be installed from cmake
>> build system, all rpaths( fastjet rpath) will be removed and it means
>> there is a place for potential problem at your side.
> Ok, this makes me even more afraid :-/ Is fastjet the only rpath that
> gets pulled in? That probably comes from the output of fastjet-config
> (another pesky config script!)
Yes, fastjet is only one rpath.
>> And I have two question about rivet itself:
>>
>> 1) rivet package contains rivetenv.(c)sh scripts and after installation
>> procedure we move it under platform directory (it was like that in
>> GENSER3). Is it possible to put it as part of rivtet automake build system?
> I'm confused: those are built as part of automake. Do you mean that you
> want our automake to *install* those scripts? We don't want to do it
> because they don't have a place in a "normal" installation tree, i.e.
> one where all packages are installed under one $prefix which is
> "automatically" visible to the user's environment. But of course quite a
> few HEP users (including Genser) install to separate prefixes, so we
> provide the script as an option to help. It'd be better if you keep
> copying that setup script... or make your own if you prefer.
Yes, it is exactly what I meant.
Now I understand your reason. Certainly we can copy it "manually". Thanks!
>
>> 2) I have noticed that GENSER3 installation stripes debug symbols from
>> rivet libraries. Any way to install rivet without debug symbols?
> There are different levels of debug symbol: Rivet is built without
> explicit symbols by default, but the ELF .so files do declare a .debug
> block, which you can see with readelf -e. Unfortunately this is the
> method used (perhaps wrongly) by ATLAS' script that checks for debug
> symbols in production external libs, so the explicit use of strip is
> required to keep that check from complaining. (With my ATLAS hat on, it
> would be ideal if Genser provided *both* opt and dbg builds, so that we
> can usefully use a debugger in our debug builds... do you know why that
> isn't done?)
I don't see any problem with building debugging symbols. I hope it will 
be implemented soon.
But it will not cancel post-installation stripping for opt platforms... 
right? ;)


Thank you for the prompt answer,

         Dima



More information about the Rivet mailing list