List of boost headers in boost/ (was RE: preprocess operation problems)
I have been involved in a discussion about the problem of keeping uptodate the header files in the top level boost/ which only get updated if they are links to the corresponding file in the boost/libs/ subdirectory which they refer to, if there is one. To give an idea of the size of the problem of headers in boost which are not links, attached is a list of all the *.hpp files in the current boost/ on develop. Only a very small number of them are links. Some of them may only contain links to headers in other directories and these will be being updated, but some of the top level headers are substantial files in themselves. These files are not being updated from when I set up the local git repository. This means that if the underlying file changes, the two get out of step. This has happened in the case of boost/integer_fwd.hpp as discussed in the other thread. My interest is to be able to maintain and update the particular library I have agreed to maintain, Boost Phoenix. That has many dependencies not only of its own but also the tools e.g. test and preprocess, which I need to use from time to time. I hope we can evolve a situation where it is clear to a maintainer what is needed to keep a consistent working environment. I know that is not easy because of the way tools, such as compilers and indeed the C++ standard itself, keep on changing. We do need a working platform which we can understand and work with. I think some of the present problems are arising because of very reasonable attempts to make boost more consistent. Some of the changes of configuration are causing problems not forseen, because of the wide interdependence of the boost libraries. John Fletcher
Thanks for that list..
On Wed, Jan 28, 2015 at 2:48 PM, Fletcher, John P
I have been involved in a discussion about the problem of keeping uptodate the header files in the top level boost/ which only get updated if they are links to the corresponding file in the boost/libs/ subdirectory which they refer to, if there is one.
To give an idea of the size of the problem of headers in boost which are not links, attached is a list of all the *.hpp files in the current boost/ on develop. Only a very small number of them are links.
Some of them may only contain links to headers in other directories and these will be being updated, but some of the top level headers are substantial files in themselves. These files are not being updated from when I set up the local git repository. This means that if the underlying file changes, the two get out of step. This has happened in the case of boost/integer_fwd.hpp as discussed in the other thread.
My interest is to be able to maintain and update the particular library I have agreed to maintain, Boost Phoenix. That has many dependencies not only of its own but also the tools e.g. test and preprocess, which I need to use from time to time.
I hope we can evolve a situation where it is clear to a maintainer what is needed to keep a consistent working environment. I know that is not easy because of the way tools, such as compilers and indeed the C++ standard itself, keep on changing. We do need a working platform which we can understand and work with.
I think some of the present problems are arising because of very reasonable attempts to make boost more consistent. Some of the changes of configuration are causing problems not forseen, because of the wide interdependence of the boost libraries.
Well.. This is certainly surprising. Given that when I look at my develop checkout I see 1816 entries. All of which, except for some dirs, are symlinks. I do expect *all* of them to be links though. So having some dirs in there seems wrong. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
AMDG On 01/28/2015 01:59 PM, Rene Rivera wrote:
Well.. This is certainly surprising. Given that when I look at my develop checkout I see 1816 entries. All of which, except for some dirs, are symlinks. I do expect *all* of them to be links though. So having some dirs in there seems wrong.
A few directories are used by multiple libraries (e.g. numeric). I don't think it's possible to make a symlink that points to more than one directory at once. The Boost.Build code creates a directory and recursively attempts to link the contents in this case. In Christ, Steven Watanabe
Hi Steven Am Mittwoch, 28. Januar 2015, 14:27:06 schrieb Steven Watanabe:
AMDG
On 01/28/2015 01:59 PM, Rene Rivera wrote:
Well.. This is certainly surprising. Given that when I look at my develop checkout I see 1816 entries. All of which, except for some dirs, are symlinks. I do expect *all* of them to be links though. So having some dirs in there seems wrong.
A few directories are used by multiple libraries (e.g. numeric). I don't think it's possible to make a symlink that points to more than one directory at once. The Boost.Build code creates a directory and recursively attempts to link the contents in this case.
At least the hard link magic is broken on Windows. My last report is http://lists.boost.org/Archives/boost/2014/07/215713.php some half year ago. I don't see the platform used for this bugreport. Maybe creating forward headers (like Qt does) is the better way... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold@gmx.eu ! Germany
Rene Rivera wrote:
Well.. This is certainly surprising. Given that when I look at my develop checkout I see 1816 entries. All of which, except for some dirs, are symlinks. I do expect *all* of them to be links though. So having some dirs in there seems wrong.
"Split" directories aren't symlinks. For example, boost/detail is a split directory, in that some of its contents are in libs/this, and others in libs/that. Long term, all directories except the top level boost/ would be symlinks, but we aren't there yet. Files should always be symlinks and never copies though. I don't know how in John's installation the files ended up being copies.
________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Peter Dimov [lists@pdimov.com] Sent: 28 January 2015 22:03 To: boost@lists.boost.org Subject: Re: [boost] List of boost headers in boost/ (was RE: preprocess operation problems)
Rene Rivera wrote:
Well.. This is certainly surprising. Given that when I look at my develop checkout I see 1816 entries. All of which, except for some dirs, are symlinks. I do expect *all* of them to be links though. So having some dirs in there seems wrong.
"Split" directories aren't symlinks. For example, boost/detail is a split directory, in that some of its contents are in libs/this, and others in libs/that. Long term, all directories except the top level boost/ would be symlinks, but we aren't there yet.
Files should always be symlinks and never copies though. I don't know how in John's installation the files ended up being copies.
I have a note of the commands I ran in January 2014 to build the setup I am running: git clone --recursive https://github.com/boostorg/boost.git modular-boost >clone.log cd modular-boost ./bootstrap.sh ./b2 headers -- to link the headers ./b2 -- to build libraries I believe it was the advice I was given. Should I have done something different? I have attached the clone.log John
participants (5)
-
Fletcher, John P -
Jürgen Hunold -
Peter Dimov -
Rene Rivera -
Steven Watanabe