[Rivet] yaml-cpp bundling and immediate Rivet 2.1.0 release?

[David Grellscheid]

Hi Andy,

thanks for the fixes. They almost work, except for "cannot find
-lrivet-yaml-cpp" in ThePEG. I'll sort that out.

  David


On 28/01/14 12:35, Andy Buckley wrote:
> On 28/01/14 13:12, David Grellscheid wrote:
>>> 1. Why don't we do something similar for all kinds of dependencies? We
>>> wouldn't necessarily have to bundle their tarball, but just "wget" it
>>> during the build? It sounds a bit unneat, but why do it for yaml, and
>>> not the others?
>>
>> Our YAML dependency is internal only. No Rivet header files depend on
>> YAML. All the other dependencies are exposed via the headers to end users.
> 
> Exactly. Maybe some others can be reduced (and I'd love to get rid of
> the old copy of Eigen1 that's been secretly bundled in Rivet for years
> and produces a squillion compiler warnings if you build against it with
> strict flags), but this was the obvious non-standard library which could
> be kept completely internal, just like we used to do (and YODA still
> does) with TinyXML.
> 
>>> 2. (Along the lines mentioned by James before) Our dependency on cmake
>>> is now explicit. Are we / Should we be thinking about moving the build
>>> system to cmake completely?
>>
>> No way. It's such an inflexible P.O.S.
> 
> :-)  I have much the same impression so far, and switching the whole
> build system would be enormously disruptive for virtually no gain. Maybe
> we review this in a few years and come to a different conclusion.
> 
>>> 3. Should we remove YAML from the bootstrap script now? I guess not,
>>> since a "proper" installation and --with-yaml_cpp=... is still the
>>> better solution, right?
>>
>> Agree, I would remove it completely from the external surface of Rivet,
>> and...
> 
> The only issues introduced by this are:
> 
> * this makes cmake mandatory, even for people who have a prebuilt
> yaml-cpp on their system. But I think that's a tiny number of people,
> and those who had to install it by hand already needed to make sure that
> they had cmake, so we may as well just make it internal.
> 
> * we need to make sure that the automake build flags are all passed to
> the bundled cmake build of yaml-cpp. This caused trouble for LHAPDF
> 6.0.5 on pre-Mavericks Macs, where the build system is a mess. I at
> least managed to get it to use the same compiler, but of course need to
> make sure that dumb stuff like that -stdlib=c++ (or whatever) and/or
> -std=c++11 flag is also passed to the yaml-cpp build. Any CMake experts
> here to advise on how to steer that thing? The docs seem to have been
> written without any expectation that there will ever be *users* who'll
> need to interact with it...
> 
>>> As for 2.1.0, I still have a few bugfixes in analyses against nan's,
>>> since YODA (as opposed to AIDA) is now aborting when it encounters
>>> nan's/inf's. I want to commit those as soon as my trunk compiles again
>>> -- I'm currently looking at /usr/bin/ld: cannot find -lyaml-cpp.
>>
>> ... that's why. The external YAML is currently broken, and there's no
>> reason to fix it (see 1. above). Andy's changes yesterday are also
>> broken in more interesting ways, so can we PLEASE hold off a rushed
>> release for at least a week to let things settle, and testing to run.
> 
> Yep, sorry about that. I think I fixed it now (only changes to the
> previous LDFLAGS etc. setup are removal of a bad-idea -L$(prefix)/lib
> and removal of -R flags for YODA and HepMC: I think these aren't needed
> but shout at me if they are, David. It compiles after "make clean" and
> runs on a small HepMC file, so I think is ok.
> 
> Cheers,
> Andy
>