[Rivet] auxiliary scripts in several generators.

[Andy Buckley]

Hi Pere et al,

I notice that ROOT has a root-config script: does that somehow survive
Grid/CVMFS relocation? I have to admit that I've only used it locally.

In my local, privately made build of ROOT I see lines like
bindir=/usr/local/bin
in this script, (I installed into prefix=/usr/local) so I suspect that
it suffers from the same problem. If so, there are *-config script
problems closer to the heart of SFT/LCG than the myriad external
generator packages! But if there's a clever trick in the there that
makes it "just work", then I'd be happy to try to put it into the
packages that I have control over.

Cheers,
Andy


On 08/04/13 23:47, David Grellscheid wrote:
> Hi Pere,
> 
>> I understand that nothing will be done.
> 
> In Herwig++ that is. I can't decide by myself for the others.
> 
>> So I will not insist but you are in my opinion wrong.
> 
> Don't misunderstand me. I'd like to be convinced, but I really cannot
> see at the moment how it can be done in Herwig. And dumping the design
> flaws of the grid lower and lower down the chain until you stop at the
> original authors of various tools is not an efficient way to solve the
> problem. If Genser comes up with a neat way of how we can work around
> this Genser-created reloc problem centrally, I'd be happy to look at it
> for Herwig++.
> 
>> The fact is that many packages (more than 100) are being re-installed
>> at various locations (shared files systems, CVMFS, etc.)
> 
> Re-installing always works anyway. It's only the raw copying of binaries
> that's problematic. Also, don't both your examples have a fixed path
> structure, so the DESTDIR approach works perfectly fine?
> 
>> making these "config'" scripts useless.
> 
> I fully agree, *-config scripts are useless other than for fairly
> mainstream end users, who need to link one or two self-written things to
> some library. I would actually say that ./configure setups that rely on
> *-config scripts for their checks are broken, and the discussion we've
> had shows why. To ease relocation, all other lookup aspects can be
> controlled with environment variables (PATH, LD_LIBRARY_PATH,
> PYTHONPATH, MANPATH), but typically *-config scripts ignore these values
> completely.
> 
>> Aiming for relocatable packages is not violating any GNU-style
>> commandment and it can be done. Indeed the GNU community is providing
>> a module to support relocation
> 
> Sure. There's also Binreloc. It works fine if all you have is binary
> executables and libs with hardcoded paths that need rewriting, but not
> easily with *-config scripts or packages like Hw++ with its own separate
> tree of generator supplementary files and their cross-relations.
> 
> As far as I see, the most straightforward solution is still a small
> number of separate builds/installations for 1) AFS, 2) CVMFS, (which
> covers all the Grid issues right there) and 3)..n) the shared file
> systems you mentioned. Rather than copying the final result over, why
> not make the build process portable, so deploying on a new shared FS is
> a button push.
> 
>   David
> 


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