Around about 08/11/11 14:34, Krigsman Kristian typed ...
We used it in a way so we could have a common code base for different platforms and then we could inject the platform dependant files into the correct place depending on what platform the user was currently working on.
If your externals are happy knowing that they'll be pulled into other things, and possibly even know where in the code hierarchy they should be, then could you embed a "config.h" *in* the external that does nothing but '#include "../../config/myexternalname.h"', where "../../config" takes you back out to a directory in the build-project ('parent' repo)?
Then your build project contains (under config) the config files for each external, instead of trying to inject them into the externals themselves.
This is (vaguely) similar to what we do for build projects that pull in a multitude of externals, each of which needs a little project-specific customisation.
-- [neil@fnx ~]# rm -f .signature [neil@fnx ~]# ls -l .signature ls: .signature: No such file or directory [neil@fnx ~]# exit