YAML include file conflicts result in build issues.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Drop the YAML .cpp and .h files into any project that has include files of 
the same name as YAML.
2. Attempt to compile.

Result:  dozens or hundreds of errors.

The issue is that YAML acts as if it's the only library in the world, and so it 
appears does one of my other libraries.  Both of them have a file that can only 
be got to with #include "node.h"(*) and this results in an unremoveable 
conflict.

Having naked include files is a very bad practice for this very reason.  All 
your (public) include files should be in a directory which is the same name as 
your package and then you'd

#include "yaml-cpp/node.h"

which is unambiguous.

(* - I'm not sure that node.h is the exact conflict file, but I'm sure an 
include conflict is the issue.)

I attempted to use cmake to build a stand-alone library that I could link to 
(though I fear I'll get the same include file conflict...)

While it was trivial to make a build with the default settings, it took me over 
an hour to get cmake to simply build a static library - and I spent over an 
hour trying simply to set my CPPFLAGS in the compilation - and failing.  

Slogging through the incredibly huge cmake documentation was miserable, and I 
couldn't answer trivial questions (like, how do I add -arch i386 to the 
CPPFLAGS?) even after a lot of work.

What's wrong with ./configure?  It's good enough for every other library I'm 
using, including the Google C++ gtest and glog - why are you crippling your 
potentially excellent package with this obscure builder?

Original issue reported on code.google.com by tom.ritc...@gmail.com on 5 Aug 2010 at 4:33

[GoogleCodeExporter]

You're absolutely right; it's been on my agenda to put all headers in a 
`yaml-cpp` folder for a while, I just haven't gotten around to it. Soon... :)

As for CMake, I can't imagine it's much worse than ./configure - for example, 
I've spent days trying to get autotools-based libraries to compile for the 
iPhone. You're right about the documentation for CMake - it's terrible.

To be honest, I really don't like CMake, but everything else seems worse. The 
one crucial feature I want is the ability to generate platform-specific project 
files, like Xcode projects on OS X and MSVC on Windows. Unfortunately, this 
throws out scons, which seemed like a promising build system.

If you have another suggestion, I'd be happy to hear it; but I'd rather avoid 
autotools.

Original comment by jbe...@gmail.com on 5 Aug 2010 at 7:52

• Changed state: Accepted

[GoogleCodeExporter]

(finally) done! (r390)

Original comment by jbe...@gmail.com on 18 Oct 2010 at 7:07

• Changed state: Fixed

[GoogleCodeExporter]

Sorry, actually r392.

Original comment by jbe...@gmail.com on 18 Oct 2010 at 7:23

[GoogleCodeExporter]

Waaay cool!  Congratulations!

By the way, I hooked it into my app a few months ago and it's been working 
fine, though we haven't made huge use of it yet (I'm actually storing data as 
Google protocol buffers - YAML is used for our cut'n'paste format, though...)

Thanks for doing this!

Original comment by tom.ritc...@gmail.com on 18 Oct 2010 at 3:31

[GoogleCodeExporter]

And let me add that this really improves the project's quality for use in other 
systems.  

The possibility of include file name collisions wasn't small at all - at least, 
I ran into one immediately and had to eventually move yaml into its own 
hermetic area as a result (which wasn't a bad move at all, really).

I think YAML is "the wave of the future" because it's easy to paste into emails 
and having a high quality C++ library will be instrumental to this.  Best 
wishes on future improvements!

Original comment by tom.ritc...@gmail.com on 18 Oct 2010 at 5:50

[GoogleCodeExporter]

Thanks for your support!

Original comment by jbe...@gmail.com on 18 Oct 2010 at 9:38