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

[Andy Buckley]

On 29/01/14 12:46, Andy Buckley wrote:
> 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...

Checked, and it's working perfectly. The only wrinkle is that cmake
ignores CPPFLAGS, but I had already sort-of anticipated that from some
mailing list archives I'd found, and was passing CXXFLAGS="$(CPPFLAGS)
$(CXXFLAGS)" which seems to be working nicely.

Still not sure about whether there is a Mac DYLDFLAGS, nor whether cmake
knows anything about it... anyone know? When we know if/how to deal with
that, I think we're done with this bundling thing.

Andy

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