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

Subject: Re: [boost] [Git] Moving beyond arm waving?
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-02-08 15:13:37

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. If we want to don't worry
we need to ensure the coherency every time.

>> * the user will need to jump to the real headers to look for details
> 
> 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 need a cleanup to ensure that removed files are no more on the
>> common
>> directory 
> 
> Yes.
> 
>> having as consequence a complete rebuild.
> 
> 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
and remove the generated headers that are missing on the new source
repository. 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.

>> Then we moved to copy instead of generate forward headers and last we
>> moved to
>> add on the SCM soft links to the real headers.  While this is done by
>> hand we
>> found it was the best compromise. I don't know if Svn or Git allows to
>> create
>> soft links on all the platforms we use.
> 
> 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.

Just my 2cts,
Vicente
-- 
View this message in context: http://boost.2283326.n4.nabble.com/Git-Moving-beyond-arm-waving-tp3254610p3276687.html
Sent from the Boost - Dev mailing list archive at Nabble.com.