[Rivet] rivet

[Andy Buckley]

On 12/04/13 15:49, Dmitri Konstantinov wrote:
> 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 :)

Phew!

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

Cool

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

No, that's always going to be necessary for libs built with libtool, I
think (not just Rivet, but probably also Herwig++, Sherpa, FastJet, etc.)

> Thank you for the prompt answer,

I was scared ;-) Sounds like it's all under control!

Andy

-- 
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.