Boost logo

Boost :

Subject: Re: [boost] trunk vs release
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-06-03 23:55:11

Bjørn Roald wrote:

> On Wednesday 03 June 2009 09:30:01 pm Vladimir Prus wrote:
>> Can you use git-submodule to implement this layout:
>> libs/
>> program_options/
>> includes/
>> boost/
>> program_options [ same content as includes above, even as
>> 'includes' is modified]
> I don't think that is something git submodules is well suited for. I doubt
> svn externals are any good either. That looks like something you need file
> system support for, aka symbolic links. Otherwise you need to run some
> command to ensure the directories are in sync. If you can not use the file
> system to ensure the content is identical, then you should select the command
> with some care.
> Build system commands, not source control system commands, seems logical. The
> build system need to ensure the sync of headers for the build anyway.
> Furthermore, build systems are good at avoiding unnecessary modifications of
> derived objects (target files). This is very important as build time would
> suffer from any simpler logic. An implicit or explicit copy rule in the build
> system for each header comes to mind. I know this to be a successful scheme
> in large build systems. Such builds generally consist of 2 passes:
> pass 1 - whenever needed, the build system:
> generate code (if you have code generation in build)
> copy public headers from source controlled location to the public location
> pass 2 - whenever needed, the build system:
> compile (against public location and component local headers only)
> link
> This can be performed per sub-projects (components) if you have good
> dependency tracking between sub-projects. Otherwise it may be wise to
> complete pass 1 for all sub-projects before starting any pass 2 build tasks.

It is not really necessary in Boost.Build -- it can detect dependencies on
generated files (including generated headers).

> commands like:
>> bjam pass1
> could be supported to update public headers without performing full build.
> Note also that such a build system "header copy" scheme, open some other
> possibilities that may be of interest as boost grows, which I do not dig into
> now.
> A file system based solution is much simpler, but I am not sure that is
> feasible as it probably is hard to do this in a portable way. You can do that
> in ClearCase as that SCM system comes with its own virtual file system for all
> development platforms.

I still have to figure what kind of links windows supports -- it seems it
supports them, but I don't yet know how that works exactly, across everything
>= XP.

- Volodya


Boost list run by bdawes at, gregod at, cpdaniel at, john at