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

[Frank Siegert]

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

Thanks, sounds logical.

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

Heh... I'm happy to hear that disruptiveness of changes is taken into
consideration!

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

I have removed yaml_cpp from the devmode in the bootstrap script now,
that seems to be working fine at the moment.

Which flags exactly do you want to pass from automake to cmake?
CXXFLAGS, LDFLAGS, ...?

Cheers,
Frank