Re: [boost] trunk vs release

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