On Thu, Jun 4, 2015 at 5:55 PM, Peter Dimov
Daniel James wrote:
My original post was a reply to a comment about the difficulty of dealing
with git modules. If you're not concerned with git modules, why did you reply to it?
Because, from context, it seemed to me that Rene didn't actually mean git modules as such, but libraries. But I may've been wrong.
I guess I meant both.. I've run into one case two times now of trying to create a git repo that is a subset of Boost but otherwise has the same structure. Here's one of them < https://github.com/grafikrobot/boost-doctools>. It was a chore to create because it went something like this: a) build the doctools (quickbook) and get errors, b) look at the mising header errors and determine which library was missing, c) find the library git repo, d) add the submodule for it at root/libs, e) repeat. This would be something I would highly consider automating the next time around. But because step (d) was actually hard as the library did not always need to go under libs, but instead needed to go in some further level deep I made various mistakes that where hard to recover from because I don't know enough about how to deal with recovering from git submodule errors to make it "easy". Although what's funny is that I've done a subset of Boost as part of a git repo now three times. The third time my memory of the previous two times made me choose to avoid that pain. Instead I wrote a Boost Build extension that made the requirement of having the Boost structure go away. The other experience is having start thinking about modular testing of libraries. And realizing that searching around for where libraries are that need to get tested is not obvious. But I've already mentioned this case at length, so I wont bore you further with it ;-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail