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

[Andy Buckley]

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

-- 
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow / PH Dept, CERN