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-tp3254610p32... Sent from the Boost - Dev mailing list archive at Nabble.com.