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

David Grellscheid david.grellscheid at durham.ac.uk
Tue Jan 28 12:12:43 GMT 2014


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

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

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

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

See you,

  David


More information about the Rivet mailing list