|
[Rivet] rivetDmitri Konstantinov Dmitri.Konstantinov at cern.chFri 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 |