preprocess operation problems
I run with all the boost libraries on develop. Today the preprocess operation will not run unless I patch the file boost/integer/common_factor_ct.hpp with the following code after the includes. #ifdef BOOST_NO_INTEGRAL_INT64_T typedef unsigned long static_gcd_type; #else typedef boost::uintmax_t static_gcd_type; #endif The compiler errors had indicated that this definition was missing. I have not traced the change which caused this problem, and I have not run preprocess for some time so don't know what happened and when. I can now run with gcc 4.6 John Fletcher
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Fletcher, John P Sent: 28 January 2015 14:43 To: boost@lists.boost.org Subject: [boost] preprocess operation problems
I run with all the boost libraries on develop.
Today the preprocess operation will not run unless I patch the file boost/integer/common_factor_ct.hpp with the following code after the includes.
#ifdef BOOST_NO_INTEGRAL_INT64_T typedef unsigned long static_gcd_type; #else typedef boost::uintmax_t static_gcd_type; #endif
The compiler errors had indicated that this definition was missing.
I have not traced the change which caused this problem, and I have not run preprocess for some time so don't know what happened and when.
I can now run with gcc 4.6
I have also found this problem (in the process of updating the documentation for Boost.Integer which has had the GCD LCM code moved from Boost.Math to Boost.Integer). There is also a namespace change from boost::math to boost::integer (subject to confirmation). I think you may also find that including boost/math_fwd.hpp 'cures' this temporarily, but your fix also looks fine to me. This should be resolved in develop soon and for the next release. HTH Paul PS Shows the cost of moving things and/or putting things in the wrong place to start with :-( --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Fletcher, John P wrote:
I run with all the boost libraries on develop.
Today the preprocess operation will not run unless I patch the file boost/integer/common_factor_ct.hpp with the following code after the includes.
#ifdef BOOST_NO_INTEGRAL_INT64_T typedef unsigned long static_gcd_type; #else typedef boost::uintmax_t static_gcd_type; #endif
I don't know what the preprocess operation is, but this definition is in boost/integer_fwd.hpp (line 164). It looks like your boost/integer_fwd.hpp header (or the link to it) hasn't been updated for some reason.
________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Peter Dimov [lists@pdimov.com] Sent: 28 January 2015 15:50 To: boost@lists.boost.org Subject: Re: [boost] preprocess operation problems
Fletcher, John P wrote:
I run with all the boost libraries on develop.
Today the preprocess operation will not run unless I patch the file boost/integer/common_factor_ct.hpp with the following code after the includes.
#ifdef BOOST_NO_INTEGRAL_INT64_T typedef unsigned long static_gcd_type; #else typedef boost::uintmax_t static_gcd_type; #endif
I don't know what the preprocess operation is, but this definition is in boost/integer_fwd.hpp (line 164). It looks like your boost/integer_fwd.hpp header (or the link to it) hasn't been updated for some reason.
I have had a dig around on this one. I do regularly update all of boost develop. I have also run ./b2 headers The explanation is like this. The copy of integer_fwd.hpp in libs/integer/include/boost has indeed been updated to January 23rd. In boost itself the file integer_fwd.hpp is not a link, it is the version put there when I installed the libraries. There is a link to the library integer -> ../libs/integer/include/boost/integer The same thing applies to integer.hpp and integer_traits.hpp. This would not matter if the headers in boost only pointed to headers that are linked. So as it stands my updating of develop has no chance of updating these files. Over to someone please. John
Fletcher, John P wrote:
I have had a dig around on this one. I do regularly update all of boost develop. I have also run ./b2 headers
The explanation is like this.
The copy of integer_fwd.hpp in libs/integer/include/boost has indeed been updated to January 23rd.
In boost itself the file integer_fwd.hpp is not a link, it is the version put there when I installed the libraries.
Odd. What platform is this? Windows or something else? (On Windows, integer_fwd.hpp should be a hard link, on something else - a symbolic link.) What do you mean when you say "I installed the libraries"? If you use Boost from git, you don't have to install it. In principle, b2 headers (which is an implicit dependency of most everything) should check that your boost/integer_fwd.hpp is out of date and relink it to libs/integer/include/boost/integer_fwd.hpp. I'm not sure why it does not do so. The workaround is usually to delete boost/ and recreate it with b2 headers, but this shouldn't be necessary, at least in theory.
________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Peter Dimov [lists@pdimov.com] Sent: 28 January 2015 17:23 To: boost@lists.boost.org Subject: Re: [boost] preprocess operation problems
Fletcher, John P wrote: I have had a dig around on this one. I do regularly update all of boost
develop. I have also run ./b2 headers
The explanation is like this.
The copy of integer_fwd.hpp in libs/integer/include/boost has indeed been updated to January 23rd.
In boost itself the file integer_fwd.hpp is not a link, it is the version put there when I installed the libraries.
Odd. What platform is this? Windows or something else?
Ubuntu Linux 12.04 with gcc 4.6 for the utilities work.
(On Windows, integer_fwd.hpp should be a hard link, on something else - a symbolic link.)
These do not look like links to me: fletcher@fletcher-desktop:~/boost_maintenance/modular-boost/boost$ ls -l int*.hpp -rw-rw-r-- 1 fletcher fletcher 4617 Jan 19 2014 integer_fwd.hpp -rw-rw-r-- 1 fletcher fletcher 11314 Jan 19 2014 integer.hpp -rw-rw-r-- 1 fletcher fletcher 8317 Jan 20 2014 integer_traits.hpp This does: rwxrwxrwx 1 fletcher fletcher 37 Jan 19 2014 integer -> ../libs/integer/include/boost/integer In the other location I have this: fletcher@fletcher-desktop:~/boost_maintenance/modular-boost/libs/integer/include/boost$ ls -l integ* -rw-rw-r-- 1 fletcher fletcher 5138 Jan 23 10:51 integer_fwd.hpp -rw-rw-r-- 1 fletcher fletcher 11589 Jan 28 16:43 integer.hpp -rw-rw-r-- 1 fletcher fletcher 8317 Jun 30 2014 integer_traits.hpp
What do you mean when you say "I installed the libraries"? If you use Boost from git, you don't have to install it.
I meant when I copied from the git repository when I started to maintain Boost Phoenix.
In principle, b2 headers (which is an implicit dependency of most everything) should check that your boost/integer_fwd.hpp is out of date and relink it to libs/integer/include/boost/integer_fwd.hpp. I'm not sure why it does not do so.
The workaround is usually to delete boost/ and recreate it with b2 headers, but this shouldn't be necessary, at least in theory.
I could try this, but what does it do with the files in /boost which are not links? Is there a file somewhere which tells it which things to copy? I have run ./b2 headers on my present setup and that runs clean. My mental model has been that if I run these commands I am up to date on develop. git checkout develop git pull --recurse-submodules git submodule update --init | added to check for new libraries. git submodule foreach git checkout develop git submodule foreach git pull | to bring everything up to date. That is what I learned when I started as a maintainer. If that is not sufficient then please indicate where I am going wrong. Thanks for the help. John
Fletcher, John P wrote:
These do not look like links to me:
fletcher@fletcher-desktop:~/boost_maintenance/modular-boost/boost$ ls -l int*.hpp -rw-rw-r-- 1 fletcher fletcher 4617 Jan 19 2014 integer_fwd.hpp -rw-rw-r-- 1 fletcher fletcher 11314 Jan 19 2014 integer.hpp -rw-rw-r-- 1 fletcher fletcher 8317 Jan 20 2014 integer_traits.hpp
Nope, they look like straight copies.
The workaround is usually to delete boost/ and recreate it with b2 headers, but this shouldn't be necessary, at least in theory.
I could try this, but what does it do with the files in /boost which are not links? Is there a file somewhere which tells it which things to copy? I have run ./b2 headers on my present setup and that runs clean.
This is a Boost.Build issue and I don't understand it very well. I have a rough idea what happens though. Boost.Build checks if it can use symlinks, which is this part of its output: Performing configuration checks - symlinks supported : no (cached) - junctions supported : yes (cached) - hardlinks supported : yes (cached) I'm on Windows (without symlink rights), so it detects that it can't symlink. For you, the output would probably be Performing configuration checks - symlinks supported : yes (cached) - hardlinks supported : yes (cached) Now, it goes to check whether to copy/hardlink/symlink boost/integer_fwd.hpp to libs/integer/include/boost/integer_fwd.hpp. It sees that it can symlink, so it assumes that the existing boost/integer_fwd.hpp is already a symlink and doesn't need to be updated. Your existing boost/integer_fwd.hpp is a file for some reason though. I don't know why. It's possible that when you originally ran b2 headers, it did not yet support symlinks, but that's just a guess, as I really don't know. This can be considered a bug in the part of Boost.Build that is responsible for the header links, but if it is, I don't know how or whether it should be fixed. Either way, if you delete your existing boost/ header directory and rerun b2 headers, the files there should now be symbolic links. I think.
My mental model has been that if I run these commands I am up to date on develop.
git checkout develop git pull --recurse-submodules git submodule update --init | added to check for new libraries. git submodule foreach git checkout develop git submodule foreach git pull | to bring everything up to date.
Yes, in theory. But there have been many occasions when the header copies/links do not update automatically, so it's still a problem from time to time.
This can be considered a bug in the part of Boost.Build that is responsible for the header links, but if it is, I don't know how or whether it should be fixed.
Looking at tools/build/src/tools/link.jam:228: rule do-file-link { local target = [ path.native [ path.relative-to [ path.pwd ] $(<) ] ] ; local source = [ path.native [ path.relative-to [ path.pwd ] $(>) ] ] ; LOCATE on $(target) = . ; DEPENDS $(.current-target) : $(target) ; if $(.can-symlink) = true { link.mklink $(target) : $(source) ; } else if $(.can-hardlink) = true { DEPENDS $(target) : $(source) ; link.hardlink $(target) : $(source) ; } else { DEPENDS $(target) : $(source) ; common.copy $(target) : $(source) ; } } the hardlink and the copy cases introduce a dependency with DEPENDS $(target) : $(source), and the symbolic link case does not. Maybe it should be changed to also introduce a dependency? Anyone familiar with Boost.Build care to comment?
________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Peter Dimov [lists@pdimov.com] Sent: 28 January 2015 18:18 To: boost@lists.boost.org Subject: Re: [boost] preprocess operation problems
This can be considered a bug in the part of Boost.Build that is responsible for the header links, but if it is, I don't know how or whether it should be fixed.
It is also important to address the issue of how maintainers of libraries can be sure they are up to date. So if there is not going to be a fix then there has to be some other way to let people know when to update files. In this case the file which became outdated is used by a number of tools, including wave, which is used to update preprocessed files when maintainers make changes to header files and want to test. So there is also a question of how to be sure that changes in configuration do not break tools across Boost. Thank you John
Fletcher, John P wrote:
It is also important to address the issue of how maintainers of libraries can be sure they are up to date.
It would probably help if you delete your current boost/ directory (the one containing the headers) and then recreate it with "b2 headers", so that we can see if the result will be as we expect, that is, boost/integer_fwd.hpp is a symlink and not a copy. Hopefully, you'd only need to do that once, and from that point on, b2 will automatically keep the links up to date. Until next time. :-)
________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Peter Dimov [lists@pdimov.com] Sent: 28 January 2015 22:11 To: boost@lists.boost.org Subject: Re: [boost] preprocess operation problems Fletcher, John P wrote:
It is also important to address the issue of how maintainers of libraries can be sure they are up to date.
It would probably help if you delete your current boost/ directory (the one containing the headers) and then recreate it with "b2 headers", so that we can see if the result will be as we expect, that is, boost/integer_fwd.hpp is a symlink and not a copy.
Hopefully, you'd only need to do that once, and from that point on, b2 will automatically keep the links up to date. Until next time. :-)
I have done that and the new list attached shows only links. Standard tests are also running correctly, showing me it is finding the headers in the new setup. Should I now do the same thing on master as well? Was there a change in the way b2 works sometime in the last 12 months, or did I set up the system incorrectly? I know there was someone else who had a similar problem to myself. Thank you John
Fletcher, John P wrote:
Was there a change in the way b2 works sometime in the last 12 months, or did I set up the system incorrectly?
Yes, it appears that there was a change, judging by the history of link.jam: https://github.com/boostorg/build/commits/develop/src/tools/link.jam Specifically, it looks like it was this Feb 5 change: https://github.com/boostorg/build/commit/3116da2b95ad02748c744a44ecec67789a9... In summary, you did nothing wrong, you just did your setup before this change. Life in develop is sometimes like that, and having to delete boost/ and rerun b2 headers a few times a year is nothing extraordinary. :-)
________________________________________ From: Boost [boost-bounces@lists.boost.org] on behalf of Peter Dimov [lists@pdimov.com] Sent: 28 January 2015 22:40 To: boost@lists.boost.org Subject: Re: [boost] preprocess operation problems Fletcher, John P wrote:
Was there a change in the way b2 works sometime in the last 12 months, or did I set up the system incorrectly?
Yes, it appears that there was a change, judging by the history of link.jam:
https://github.com/boostorg/build/commits/develop/src/tools/link.jam
Specifically, it looks like it was this Feb 5 change:
https://github.com/boostorg/build/commit/3116da2b95ad02748c744a44ecec67789a9...
In summary, you did nothing wrong, you just did your setup before this change. Life in develop is sometimes like that, and having to delete boost/ and rerun b2 headers a few times a year is nothing extraordinary. :-)
Thank you that is very helpful. I have run the same changes on master and all tests have worked as expected for Phoenix. I have added this to my collection of knowledge about being a maintainer. It has been an interesting experience being a maintainer without having been the author of any of the libraries. Thank you again John _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Fletcher, John P Sent: 28 January 2015 22:25 To: boost@lists.boost.org Subject: Re: [boost] preprocess operation problems
I know there was someone else who had a similar problem to myself.
I have for one, more than once.
Hopefully, you'd only need to do that once, and from that point on, b2 will automatically keep the links up to date. Until next time. :-)
I find 'Until next time' much more worrying than some people obviously. Shouldn't we be asking "Why does this happen?" a bit more ? Yours anxiously, Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
AMDG On 01/28/2015 11:18 AM, Peter Dimov wrote:
This can be considered a bug in the part of Boost.Build that is responsible for the header links, but if it is, I don't know how or whether it should be fixed.
Looking at tools/build/src/tools/link.jam:228:
rule do-file-link <snip>
the hardlink and the copy cases introduce a dependency with DEPENDS $(target) : $(source), and the symbolic link case does not. Maybe it should be changed to also introduce a dependency? Anyone familiar with Boost.Build care to comment?
I think you are correct. Adding this dependency should fix this specific problem. It will cause the symlink to be recreated when it's already correct in some obscure cases, but there's nothing currently around that would trigger this and it's fairly harmless anyway. In Christ, Steven Watanabe
participants (4)
-
Fletcher, John P -
Paul A. Bristow -
Peter Dimov -
Steven Watanabe