Addressing the YAML topics:
* I have pushed your commit, plus my non-contentious updates, to
spi/yaml. Once build issues are worked out, this will be moved to
spi/master (and delete the yaml branch). +1 for GIT.
* We are on Cmake 2.8 @ Imageworks, I was just making the observation
that your use bumps up the required version from it's prior 2.6 value.
* Unfortunately, the compile issue I'm having does not appear to be
tied to the namespace stuff. Does your yaml branch currently build? On
my linux box, it does not. What OS are you testing on?
- OSX 10.6
- CentOS 5.3
- Debian squeeze (testing)
I tried for about 30 min today to find a fix, but could not figure it
out. I still believe the fix is to pass the -fPIC flag to the yaml
compilation, but was not able to figure out how to get this passed
along. (It's easy to verify though with make VERBOSE=1). I'll look
into this more tomorrow.
do you mean adding this to the yaml-cpp project?
* "The dev on yaml-cpp is pretty active
(http://code.google.com/p/yaml-cpp/updates/list) ... If we were
choosing to fork yaml-cpp (which I don't think we are) or other ext
dependants, checking them in would be fine and would help to indicate
Ok. I'll take the bait.
What's the argument against forking our internal dependencies? (I.e.,
locking off on the known working versions of yaml-cpp, tinyxml,
pystring, and md5)
If these were all live libraries (.tgz(s) in externals) - something
that could be updated easily - people would be inclined to bump up
when new versions of the libs are released. And, this feels counter
to the "if it aint broke, dont fix it" philosophy. If any of these
libraries were exposed in the public headers, it would be a different
situation. But seeing as they're all intended to be 100% private,
updating them on a semi-frequent basis (or making it easy to do so)
probably only has the potential to introduce bugs. Also, even if we
do go the .tgz route, we'll need non-trivial .patch files for the
namespace adjustments, which makes updating versions not trivial
What new yaml development is being done? I had been presuming that the
core library we're considering using is rock solid in both API and
The downside of forking, of course, is that we wouldn't be getting bug
fix releases, but when / if we encounter serialization bugs they'll
(hopefully) be obvious, and we could then update on an as-needed.
Yaml has 64 files, and it took me approx 15 min to namespace it so
re-doing that work as needed is not a huge issue.
I acknowledge that forking code feels a bit dirty though.
For the code voyeurs out there, here's what a fork'd yaml looks like:
No bait intended :) I guess this comes down to a bit of personal choice.
Just because an external is in a .tgz shouldn't mean the version isn't any more unlocked than if it's checked in. Any private externals being updated should be tested the same way you would if you were merging in changes in the repo. dare I say test coverage? :)
I personally like being able to see in a single patch file the modifications that have been done to an external, regardless if the patch applies cleanly on a new version or not.
Updating an external with out a difference file seems like it would add more potential to miss any internal bug fixes we might do to an external ie the namespace change is pretty easy to spot, but if the changes are more esoteric then it might be missed in an update. Getting your hands on the un-patched version to do a diff to see the changes and then update the new version also seems a bit painful.
Regardless if we choose to have it as files or tgz in the repo, can we have the externals outside of the core/src dir? would make greping / searching for things like 'xml' or 'yaml' a bit more descriptive.
I hadn't seen this before (on non-windows), but it looks interesting.
I like the concept, I'll look into it more. (It will probably have
implications with regards to exceptions, but that's arguably a good
topic to revisit anyways).
I was also looking at GNU Export Maps (http://accu.org/index.php/journals/1372
) which doesn't look as portable. eg.http://open.rsp.com.au/projects/pyshake/browser/trunk/plugin.exphttp://open.rsp.com.au/projects/pyshake/browser/trunk/pyshake.export.map
This is also a good overview as well for maintaing ABI (http://people.redhat.com/drepper/dsohowto.pdf