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

[Andy Buckley]

On 29/01/14 11:32, Frank Siegert 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.
> 
> 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!

;-)

Always. But sometimes they are worth it -- it can be a tough call.

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

Thanks.

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

Yes: these are the user-set flags, which presumably they wanted to apply
to the whole library. For Macs is there also a DYLDFLAGS, in the way
that there is a DYLD_LIBRARY_PATH (grr)? In particular this was reported
to us for LHAPDF 6.0.5 as being an issue on Macs where the stdlib
version needs to be specified with an explicit flag. [*]

Automake automatically appends these variables to the relevant
compiler/linker lines, but I think they need to be manually passed to
cmake somehow. At present I'm trying to pass these, plus the CXX
variable, in the src/Core/yamlcpp/Makefile.am that calls cmake.

By building rivet-yaml-cpp via "make VERBOSE=1" in that Makefile.am, I
can see that the CXX variable is definitely working -- otherwise it
falls back to trying to find a compiler proxy called "c++" -- but I'm
not sure about the CXXFLAGS and LDFLAGS. I just realised a flaw in how I
was testing that, so will try again now and let you know...

Andy

[*] Maybe that's less of an issue now as I've taken out the auto-C++11
usage after negative feedback, until it becomes mandatory i.e. there is
enough compiler support in a typical installation to allow us to do so.

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