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

[Andy Buckley]

Good. Sorry for the mess.

How is ThePEG getting to know about -lrivet-yaml-cpp? In my current
build it's not referenced from any of libRivet.so, libRivet.la, or
rivet-config!

Andy


On 28/01/14 13:47, David Grellscheid wrote:
> 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
>>


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