Re: [boost] [Git] Moving beyond arm waving?

Subject: Re: [boost] [Git] Moving beyond arm waving?
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-02-08 15:35:54

At Tue, 8 Feb 2011 12:13:37 -0800 (PST),
Vicente Botet wrote:
> 
> 
> 
> Dave Abrahams wrote:
> > 
> > At Mon, 7 Feb 2011 22:27:20 -0800 (PST),
> > Vicente Botet wrote:
> >> 
> >> 
> >> 
> >> Dave Abrahams wrote:
> >> > 
> >> > At Mon, 07 Feb 2011 09:53:52 -0600,
> >> > Rene Rivera wrote:
> >> >> I would also like to know:
> >> >> 
> >> >> 1. How does that non-versioned complete integrated tree work as
> >> regards
> >> >> to
> >> >>    updates/pulls?
> >> > 
> >> > Today, you call GenHeaders explicitly, but if you check out Marcus'
> >> work
> >> > you
> >> > don't have to.
> >> > 
> >> 
> >> I worked with a build system that did something like that, generate
> >> headers
> >> to a common directory tree that forwards to the real header files. This
> >> has
> >> some drawbacks:
> >> 
> >> * it takes time to generate the headers 
> > 
> > I suppose.  You only have to do it once.
> > 
> 
> Once every time there is a possibility to have a new file.  That means once
> after each update, cleanup or additional header created manually. For non
> incremental builds this must be done every time. 

You only have to generate a forwarding header when you actually have a new
header file.  Yes, you have to check for the existence of forwarding headers
each time, but that's not the same cost as actually generating them.

> > Jump there from where?  Any error messages will point at the real headers. 
> > What
> > else is there?
> > 
> 
> The problem didn't was in order to check for error messages, but to just
> read the sources.
> I remember now, the problem was that the tree directory structure was not
> preserved (the include directory was flat) , and the people didn't know from
> which directory the files were generated until they look into its contents.
> 
> If the directory structure is preserved there is no issue.

We would preserve the structure.

> > Huh?  I don't see why that should be necessary.  Just remove the right
> > forwarding headers and you're golden.
> 
> This is not so simple. The build system needs to compare both repositories

No repository action is needed.  This all operates on regular directory trees.

> and remove the generated headers that are missing on the new source
> repository. 

What's not-so-simple about that?

> This again need to be done each time a file could be removed.  That is after
> each update or explicit header removal. If we want to don't worry we need to
> ensure the coherency every time.

So we'll do that.  I don't get what you're worried about.

> > If you mean a soft link in the filesystem, I think the answer is that some
> > OS platforms don't support them.  If you mean something else, I need
> > clarification.
> 
> You are right. We were on Unix-like systems. The same links were not visible
> under windows.
> 
> What I'm doing now when I test my on going libraries respect to a given boost
> version, and I think most of the people developing new libraries, is to
> checkout the header library directory directly in the boost root directory. In
> this way there is no need to generate any header. I do it also for other
> libraries that use a git repository without any trouble.
> 
> Maybe this schema merits some reflection if we want to work with multiple
> modular libraries and possibility with different SCM systems and preserve
> the proved current system.

I don't mind reflecting on it, but this has nothing to do with SCMs.  You'd have
the same problem even if you (for some insane reason) wanted to do development
without source control.  As for preserving the current system, I have little
interest in that.

If you want to be able to test an *installed* boost (and I think it's crucial),
you need to accept the idea that the headers being used for compiling tests are
different than the ones in your source distribution, because an *installation*
of Boost generally doesn't include all the sources.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com