On 5 June 2015 at 03:50, Rene Rivera
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.
I'd see that a something that's just too painful to do, regardless of module locations. But if you must, instead of adding the modules to a repo, I'd create a clean clone of the super project and only initialise the modules that I need. That way you can quickly grab all the numeric modules using: git submodule update --init -- libs/numeric/ And pretend they're a single module. Which means you'll get a few extra modules - but only a few. Since Boost Build scans for include files, is it possible to get it to list all the files it thinks are required? I realise it's not entirely accurate because of macros, but hopefully it would be good enough. Or perhaps get it to run 'g++ -H' or 'cl /showIncludes' to tell which files were used. With that information it shouldn't be that hard to work out which modules are required.