[Rivet] Warning: change to analysis loader!

[Andy Buckley]

Frank Siegert wrote:
> Hi Andy,
> 
> Andy Buckley, Friday 28 August 2009:
>> Be careful about updating Rivet SVN at the moment: today I made some
>> major commits which break backwards compatibility and will probably
>> interact unhappily with existing installations.
>>
>> The changes consist of a new analysis plugin loader system which
>> reduces the boilerplate code required when writing an analysis
>> (including removing the need for analysis header files), and also make
>> it easier to split the plugin analyses into multiple per-expt
>> libraries. The new loader system now only loads plugin libraries of the
>> form Rivet*.so, (i.e. the old name lib*Rivet*.so won't be loaded) and
>> the loading mechanism and API are completely different. The
>> AnalysisLoader package also changed, so the bundled pyext files will
>> break: for now, please either use HepMC 2.5, for which I've done the
>> update, or delete the rivet_wrap.cc* and rivet.py* files.
> 
> Thank you very much for this great improvement in the analysis loader 
> mechanism, it looks very elegant. I have fixed a small remaining issue 
> with the JADE_OPAL analyses, and it seems to be working nicely at a first 
> glance now.

Thanks! I couldn't work out what was going on here.

> I have a couple of related questions:
> 
> - Out of curiosity: What is the reasoning behind moving the analyses into 
> separate subdirectories/libraries?

Partially it was a request from Peter Richardson, since the directory 
was getting crowded, but IMO it's also nice to be able to build/install 
sets of analyses as a test, without having to wait for all of them to 
finish.

> - Is there any practical reason for moving from libRivet*.so to Rivet*.so? 
> The old version seemed to make sense to me, as it is a library after all.

libtool recommends this name form for plugin modules: in this mode the 
Mac suffix also becomes .so, which improves predictability (actually, 
I've not made the loader respect this, so it may be currently broken on 
Macs right now). So it's partially because this is the convention for 
libraries which are not really designed to be linked against, but also 
because I think it's useful to avoid clashes between old installed 
plugins and the new sort.

> - In the doc directory, building currently fails with the message
>     Tried to register a second plugin analysis called ''
> This happens because it tries to read files like
> [...]/trunk/src/share/Rivet/CDF_2009_S8233977.info
> when ../src/.libs is in the LD_LIBRARY_PATH due to binreloc I suppose. Do 
> you have any idea how to work around this?

Ah, I wasn't sure what was going on there. Yes, I can make this work: it 
might involve adding some path search functionality, so not sure about 
the timescale. But it's not a total blocker in its current state, I think...

Andy