[testing] mpl/core tests not visible
Hi, I can see a few testers have cycled since MPL.Core was extracted into a sublibrary, but there is no mpl/core page in the test matrix. The sublibs file and core/test directory are present in the mpl submodule. Is there something I should do to make the tests appear?
Le 11/09/14 20:06, Andrey Semashev a écrit :
Hi,
I can see a few testers have cycled since MPL.Core was extracted into a sublibrary, but there is no mpl/core page in the test matrix. The sublibs file and core/test directory are present in the mpl submodule. Is there something I should do to make the tests appear?
I'm not sure, but take a look at status/Jamfile.v2 There is a list as # Tests from Jamfiles in individual library test subdirectories # Please keep these in alphabetic order by test-suite name run-tests libs : accumulators/test # test-suite accumulators algorithm/test # test-suite algorithm algorithm/minmax/test # test-suite algorith/minmax algorithm/string/test # test-suite algorithm/string align/test # test-suite align array/test # test-suite array asio/test # test-suite asio assert/test # test-suite assert ... Best, Vicente
On Friday 12 September 2014 20:23:46 Vicente J. Botet Escriba wrote:
Le 11/09/14 20:06, Andrey Semashev a écrit :
Hi,
I can see a few testers have cycled since MPL.Core was extracted into a sublibrary, but there is no mpl/core page in the test matrix. The sublibs file and core/test directory are present in the mpl submodule. Is there something I should do to make the tests appear?
I'm not sure, but take a look at status/Jamfile.v2
There is a list as
# Tests from Jamfiles in individual library test subdirectories # Please keep these in alphabetic order by test-suite name run-tests libs : accumulators/test # test-suite accumulators algorithm/test # test-suite algorithm algorithm/minmax/test # test-suite algorith/minmax algorithm/string/test # test-suite algorithm/string align/test # test-suite align array/test # test-suite array asio/test # test-suite asio assert/test # test-suite assert ...
Thanks for the hint. https://github.com/boostorg/boost/pull/38
On Sep 11, 2014, at 12:06 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
I can see a few testers have cycled since MPL.Core was extracted into a sublibrary, but there is no mpl/core page in the test matrix. The sublibs file and core/test directory are present in the mpl submodule. Is there something I should do to make the tests appear?
Hijacking this thread, briefly. I’m getting this error with nightly Darwin builds since I pushed the MPL commit, seems like it's probably related. ./boost/mpl/aux_/include_preprocessed.hpp:37:13: fatal error: 'boost/mpl/aux_/preprocessed/gcc/arg.hpp' file not found # include BOOST_PP_STRINGIZE(boost/mpl/aux_/preprocessed/AUX778076_PREPROCESSED_HEADER) ^ ./boost/preprocessor/stringize.hpp:28:38: note: expanded from macro 'BOOST_PP_STRINGIZE' # define BOOST_PP_STRINGIZE(text) BOOST_PP_STRINGIZE_I(text) ^ ./boost/preprocessor/stringize.hpp:31:37: note: expanded from macro 'BOOST_PP_STRINGIZE_I' # define BOOST_PP_STRINGIZE_I(text) #text ^ Do we need to regenerate the preprocessed headers?
On Saturday 13 September 2014 03:02:54 Belcourt, Kenneth wrote:
On Sep 11, 2014, at 12:06 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
I can see a few testers have cycled since MPL.Core was extracted into a sublibrary, but there is no mpl/core page in the test matrix. The sublibs file and core/test directory are present in the mpl submodule. Is there something I should do to make the tests appear?
Hijacking this thread, briefly.
I’m getting this error with nightly Darwin builds since I pushed the MPL commit, seems like it's probably related.
./boost/mpl/aux_/include_preprocessed.hpp:37:13: fatal error: 'boost/mpl/aux_/preprocessed/gcc/arg.hpp' file not found # include BOOST_PP_STRINGIZE(boost/mpl/aux_/preprocessed/AUX778076_PREPROCESSED_HEADE R) ^ ./boost/preprocessor/stringize.hpp:28:38: note: expanded from macro 'BOOST_PP_STRINGIZE' # define BOOST_PP_STRINGIZE(text) BOOST_PP_STRINGIZE_I(text) ^ ./boost/preprocessor/stringize.hpp:31:37: note: expanded from macro 'BOOST_PP_STRINGIZE_I' # define BOOST_PP_STRINGIZE_I(text) #text ^
Hmm, which testers show that? I can see all tests are green, except for Intel, which was failing before the merge.
Do we need to regenerate the preprocessed headers?
We shouldn't be, the file is there: https://github.com/boostorg/mpl/blob/develop/include/boost/mpl/aux_/preproce... The only thing that is needed is 'b2 headers'. I also deleted the boost directory prior to it, but it may not be required.
On Sep 12, 2014, at 11:39 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Saturday 13 September 2014 03:02:54 Belcourt, Kenneth wrote:
On Sep 11, 2014, at 12:06 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
I can see a few testers have cycled since MPL.Core was extracted into a sublibrary, but there is no mpl/core page in the test matrix. The sublibs file and core/test directory are present in the mpl submodule. Is there something I should do to make the tests appear?
Hijacking this thread, briefly.
I’m getting this error with nightly Darwin builds since I pushed the MPL commit, seems like it's probably related.
./boost/mpl/aux_/include_preprocessed.hpp:37:13: fatal error: 'boost/mpl/aux_/preprocessed/gcc/arg.hpp' file not found # include BOOST_PP_STRINGIZE(boost/mpl/aux_/preprocessed/AUX778076_PREPROCESSED_HEADE R) ^ ./boost/preprocessor/stringize.hpp:28:38: note: expanded from macro 'BOOST_PP_STRINGIZE' # define BOOST_PP_STRINGIZE(text) BOOST_PP_STRINGIZE_I(text) ^ ./boost/preprocessor/stringize.hpp:31:37: note: expanded from macro 'BOOST_PP_STRINGIZE_I' # define BOOST_PP_STRINGIZE_I(text) #text ^
Hmm, which testers show that? I can see all tests are green, except for Intel, which was failing before the merge.
Both Sandia Darwin testers on develop stopped cycling Wednesday following the push.
Do we need to regenerate the preprocessed headers?
We shouldn't be, the file is there:
https://github.com/boostorg/mpl/blob/develop/include/boost/mpl/aux_/preproce...
The only thing that is needed is 'b2 headers'. I also deleted the boost directory prior to it, but it may not be required.
Tried this, didn’t help.
On Sat, Sep 13, 2014 at 9:30 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Sep 12, 2014, at 11:39 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Do we need to regenerate the preprocessed headers?
We shouldn't be, the file is there:
https://github.com/boostorg/mpl/blob/develop/include/boost/mpl/aux_/preproce...
The only thing that is needed is 'b2 headers'. I also deleted the boost directory prior to it, but it may not be required.
Tried this, didn’t help.
Multiple other testers are running fine, including Sandia gcc, so I think this is something specific for this particular tester. Do you have access to the testing machine? What is the result and output of the 'b2 headers' command? The correct result (the one I'm having) is that boost/mpl is a normal directory, and all files, including arg.hpp, are links to the files in libs/mpl and libs/mpl/core. Also, could you check that Jamroot is the latest?
On Sep 13, 2014, at 1:39 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Sat, Sep 13, 2014 at 9:30 PM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
On Sep 12, 2014, at 11:39 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
Do we need to regenerate the preprocessed headers?
We shouldn't be, the file is there:
https://github.com/boostorg/mpl/blob/develop/include/boost/mpl/aux_/preproce...
The only thing that is needed is 'b2 headers'. I also deleted the boost directory prior to it, but it may not be required.
Tried this, didn’t help.
Multiple other testers are running fine, including Sandia gcc, so I think this is something specific for this particular tester. Do you have access to the testing machine? What is the result and output of the 'b2 headers' command? The correct result (the one I'm having) is that boost/mpl is a normal directory, and all files, including arg.hpp, are links to the files in libs/mpl and libs/mpl/core.
Also, could you check that Jamroot is the latest?
Looks like a change in how b2 runs. IIRC, running b2, without specifying the headers target, would look for the boost directory and, if not found, would run the headers target, and then proceed with the build. It now seems that if b2 is run (no boost directory and no header target specified on the command line), only about 250 files are installed into the boost directory, and then b2 starts compiling code. An explicit 'b2 headers' installs over 1300 headers. This is the source of the nightly testing problem, the run script doesn’t explicitly invoke ‘b2 headers’, it first builds b2 then proceeds to build process_jam_log resulting in a subset of headers being installed and process_jam_log.cpp failing to compile due to missing headers. Most / all non-Linux develop testers have stopped cycling so it seems we need to get this fixed ASAP. One possible resolution is to not try to figure out the change in b2 behavior and fix the nightly testing to explicitly invoke ‘b2 headers’. I suspect that would get the testers cycling again. Not sure how users might feel about the change in b2 behavior though. — Noel
On Saturday 13 September 2014 20:46:40 Belcourt, Kenneth wrote:
Looks like a change in how b2 runs. IIRC, running b2, without specifying the headers target, would look for the boost directory and, if not found, would run the headers target, and then proceed with the build. It now seems that if b2 is run (no boost directory and no header target specified on the command line), only about 250 files are installed into the boost directory, and then b2 starts compiling code. An explicit 'b2 headers' installs over 1300 headers.
So, to be clear, with explicit 'b2 headers' it compiles as expected?
This is the source of the nightly testing problem, the run script doesn’t explicitly invoke ‘b2 headers’, it first builds b2 then proceeds to build process_jam_log resulting in a subset of headers being installed and process_jam_log.cpp failing to compile due to missing headers.
Most / all non-Linux develop testers have stopped cycling so it seems we need to get this fixed ASAP. One possible resolution is to not try to figure out the change in b2 behavior and fix the nightly testing to explicitly invoke ‘b2 headers’. I suspect that would get the testers cycling again. Not sure how users might feel about the change in b2 behavior though.
I suppose, the expectation is that b2 will infer the dependent headers from the compiled sources somehow and installs them. It's possible that it is not able to pass through the preprocessor magic used in MPL. I think there was a discussion some time ago about some headers not being automatically installed this way. Although that doesn't explain why only some testers were broken. Anyway, IMHO, 'b2 headers' should be explicitly invoked by the testing scripts.
On Sep 13, 2014, at 3:11 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Saturday 13 September 2014 20:46:40 Belcourt, Kenneth wrote:
Looks like a change in how b2 runs. IIRC, running b2, without specifying the headers target, would look for the boost directory and, if not found, would run the headers target, and then proceed with the build. It now seems that if b2 is run (no boost directory and no header target specified on the command line), only about 250 files are installed into the boost directory, and then b2 starts compiling code. An explicit 'b2 headers' installs over 1300 headers.
So, to be clear, with explicit 'b2 headers' it compiles as expected?
Yes.
This is the source of the nightly testing problem, the run script doesn’t
explicitly invoke ‘b2 headers’, it first builds b2 then proceeds to build process_jam_log resulting in a subset of headers being installed and process_jam_log.cpp failing to compile due to missing headers.
Most / all non-Linux develop testers have stopped cycling so it seems we need to get this fixed ASAP. One possible resolution is to not try to figure out the change in b2 behavior and fix the nightly testing to explicitly invoke ‘b2 headers’. I suspect that would get the testers cycling again. Not sure how users might feel about the change in b2 behavior though.
I suppose, the expectation is that b2 will infer the dependent headers from the compiled sources somehow and installs them. It's possible that it is not able to pass through the preprocessor magic used in MPL. I think there was a discussion some time ago about some headers not being automatically installed this way. Although that doesn't explain why only some testers were broken.
It’s because I don’t remove the existing boost directory so it’s already fully (correctly) populated. These testers will also fail if I remove their boost directories.
Anyway, IMHO, 'b2 headers' should be explicitly invoked by the testing scripts.
Right, testers would be okay with that though I think a breaking change like this needs a bit more visibility so that testers, developers, and others, understand this change. — Noel
On Saturday 13 September 2014 21:25:58 Belcourt, Kenneth wrote:
On Sep 13, 2014, at 3:11 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
I suppose, the expectation is that b2 will infer the dependent headers from the compiled sources somehow and installs them. It's possible that it is not able to pass through the preprocessor magic used in MPL. I think there was a discussion some time ago about some headers not being automatically installed this way. Although that doesn't explain why only some testers were broken.
It’s because I don’t remove the existing boost directory so it’s already fully (correctly) populated. These testers will also fail if I remove their boost directories.
Anyway, IMHO, 'b2 headers' should be explicitly invoked by the testing scripts.
Right, testers would be okay with that though I think a breaking change like this needs a bit more visibility so that testers, developers, and others, understand this change.
It is possible that this never worked before, not in complicated cases like MPL anyway. At some point someone ran 'b2 headers' or something similar on the test machine, and it worked while the headers layout in submodules was more or less stable.
On Sep 13, 2014, at 4:06 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Saturday 13 September 2014 21:25:58 Belcourt, Kenneth wrote:
On Sep 13, 2014, at 3:11 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
I suppose, the expectation is that b2 will infer the dependent headers from the compiled sources somehow and installs them. It's possible that it is not able to pass through the preprocessor magic used in MPL. I think there was a discussion some time ago about some headers not being automatically installed this way. Although that doesn't explain why only some testers were broken.
It’s because I don’t remove the existing boost directory so it’s already fully (correctly) populated. These testers will also fail if I remove their boost directories.
Anyway, IMHO, 'b2 headers' should be explicitly invoked by the testing scripts.
Right, testers would be okay with that though I think a breaking change like this needs a bit more visibility so that testers, developers, and others, understand this change.
It is possible that this never worked before, not in complicated cases like MPL anyway. At some point someone ran 'b2 headers' or something similar on the test machine, and it worked while the headers layout in submodules was more or less stable.
No, this definitely worked fine before (i.e. worked without having to run 'b2 headers’). For example, the nightly testers (Sandia-darwin) only broke following the push to MPL because they always start from a clean directory with nothing checked out or installed. Since the nightly testers don’t run ‘b2 headers’, that means that b2 was able to correctly install the headers needed to build process_jam_log during the testing process. The ability to correctly install the headers for the targets being built is what’s currently broken, unless someone does a ‘b2 headers’ first to install everything. So I think we need to revert the MPL change unless we can figure out how to fix it. I agree there’s a workaround by installing all the headers with ‘b2 headers' but we broke major functionality in b2 with this commit, yikes! — Noel
On Saturday 13 September 2014 22:54:48 Belcourt, Kenneth wrote:
No, this definitely worked fine before (i.e. worked without having to run 'b2 headers’). For example, the nightly testers (Sandia-darwin) only broke following the push to MPL because they always start from a clean directory with nothing checked out or installed. Since the nightly testers don’t run ‘b2 headers’, that means that b2 was able to correctly install the headers needed to build process_jam_log during the testing process. The ability to correctly install the headers for the targets being built is what’s currently broken, unless someone does a ‘b2 headers’ first to install everything.
So I think we need to revert the MPL change unless we can figure out how to fix it. I agree there’s a workaround by installing all the headers with ‘b2 headers' but we broke major functionality in b2 with this commit, yikes!
I don't see how rearranging some headers in MPL could have broken Boost.Build, unless it was broken before and worked incidentally. IMHO, reverting the change is not the fix, it might cover the problem at the very best. You can try it locally on the testing machine to see if it really helps.
On Sunday 14 September 2014 10:55:03 you wrote:
On Saturday 13 September 2014 22:54:48 Belcourt, Kenneth wrote:
No, this definitely worked fine before (i.e. worked without having to run 'b2 headers’). For example, the nightly testers (Sandia-darwin) only broke following the push to MPL because they always start from a clean directory with nothing checked out or installed. Since the nightly testers don’t run ‘b2 headers’, that means that b2 was able to correctly install the headers needed to build process_jam_log during the testing process. The ability to correctly install the headers for the targets being built is what’s currently broken, unless someone does a ‘b2 headers’ first to install everything.
So I think we need to revert the MPL change unless we can figure out how to fix it. I agree there’s a workaround by installing all the headers with ‘b2 headers' but we broke major functionality in b2 with this commit, yikes!
I don't see how rearranging some headers in MPL could have broken Boost.Build, unless it was broken before and worked incidentally. IMHO, reverting the change is not the fix, it might cover the problem at the very best. You can try it locally on the testing machine to see if it really helps.
BTW, in tools/regression/build/Jamroot.jam I can see this: exe process_jam_log : process_jam_log.cpp tiny_xml /boost/filesystem//boost_filesystem/<link>static : <define>BOOST_ALL_NO_LIB=1 <define>_CRT_SECURE_NO_WARNINGS <implicit-dependency>/boost//headers : release ; The headers dependency is also present in other targets for testing tools. So, unless I'm missing something, the headers target should have been invoked before the tool is built. Maybe the problem is that Filesystem (as probably all other libraries) don't depend on headers and can be built before the headers are installed? I think the correct temporary workaround is to add 'b2 headers' to testing scripts. The long term fix is probably to add the dependency on headers to all libraries that build, tests and examples. That is if the problem is not elsewhere. I'd like to hear from Boost.Build guys on this.
On Saturday 13 September 2014 22:54:48 Belcourt, Kenneth wrote:
No, this definitely worked fine before (i.e. worked without having to run 'b2 headers’). For example, the nightly testers (Sandia-darwin) only broke following the push to MPL because they always start from a clean directory with nothing checked out or installed. Since the nightly testers don’t run ‘b2 headers’, that means that b2 was able to correctly install the headers needed to build process_jam_log during the testing process. The ability to correctly install the headers for the targets being built is what’s currently broken, unless someone does a ‘b2 headers’ first to install everything.
I think I know why it worked before. Before the change the boost/mpl directory was a link to libs/mpl/include/boost/mpl. The link was created due to a dependency on some public MPL header, but it 'installed' all MPL headers, including those that were not discovered by Boost.Build due to preprocessor tricks. Now every file in boost/mpl is a link, and the problem appears on the surface.
On Sep 14, 2014, at 1:46 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Saturday 13 September 2014 22:54:48 Belcourt, Kenneth wrote:
No, this definitely worked fine before (i.e. worked without having to run 'b2 headers’). For example, the nightly testers (Sandia-darwin) only broke following the push to MPL because they always start from a clean directory with nothing checked out or installed. Since the nightly testers don’t run ‘b2 headers’, that means that b2 was able to correctly install the headers needed to build process_jam_log during the testing process. The ability to correctly install the headers for the targets being built is what’s currently broken, unless someone does a ‘b2 headers’ first to install everything.
I think I know why it worked before. Before the change the boost/mpl directory was a link to libs/mpl/include/boost/mpl. The link was created due to a dependency on some public MPL header, but it 'installed' all MPL headers, including those that were not discovered by Boost.Build due to preprocessor tricks. Now every file in boost/mpl is a link, and the problem appears on the surface.
Yes, that does sound like the issue. So, what do you think we should do about it? — Noel
On Monday 15 September 2014 14:15:48 Belcourt, Kenneth wrote:
On Sep 14, 2014, at 1:46 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Saturday 13 September 2014 22:54:48 Belcourt, Kenneth wrote:
No, this definitely worked fine before (i.e. worked without having to run 'b2 headers’). For example, the nightly testers (Sandia-darwin) only broke following the push to MPL because they always start from a clean directory with nothing checked out or installed. Since the nightly testers don’t run ‘b2 headers’, that means that b2 was able to correctly install the headers needed to build process_jam_log during the testing process. The ability to correctly install the headers for the targets being built is what’s currently broken, unless someone does a ‘b2 headers’ first to install everything.
I think I know why it worked before. Before the change the boost/mpl directory was a link to libs/mpl/include/boost/mpl. The link was created due to a dependency on some public MPL header, but it 'installed' all MPL headers, including those that were not discovered by Boost.Build due to preprocessor tricks. Now every file in boost/mpl is a link, and the problem appears on the surface.
Yes, that does sound like the issue. So, what do you think we should do about it?
As I suggested in another reply, I think we should add 'b2 headers' to the testing scripts as a hotfix. I'd create a pull request, but I have no idea how the testing works and where this command should be added. The long term fix is probably figure out why the headers target is not built first before process_jam_log (I described my theory in another reply) and fix it. This will probably require attention of the Boost.Build team.
On Sep 15, 2014, at 9:17 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Monday 15 September 2014 14:15:48 Belcourt, Kenneth wrote:
On Sep 14, 2014, at 1:46 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Saturday 13 September 2014 22:54:48 Belcourt, Kenneth wrote:
No, this definitely worked fine before (i.e. worked without having to run 'b2 headers’). For example, the nightly testers (Sandia-darwin) only broke following the push to MPL because they always start from a clean directory with nothing checked out or installed. Since the nightly testers don’t run ‘b2 headers’, that means that b2 was able to correctly install the headers needed to build process_jam_log during the testing process. The ability to correctly install the headers for the targets being built is what’s currently broken, unless someone does a ‘b2 headers’ first to install everything.
I think I know why it worked before. Before the change the boost/mpl directory was a link to libs/mpl/include/boost/mpl. The link was created due to a dependency on some public MPL header, but it 'installed' all MPL headers, including those that were not discovered by Boost.Build due to preprocessor tricks. Now every file in boost/mpl is a link, and the problem appears on the surface.
Yes, that does sound like the issue. So, what do you think we should do about it?
As I suggested in another reply, I think we should add 'b2 headers' to the testing scripts as a hotfix. I'd create a pull request, but I have no idea how the testing works and where this command should be added.
I‘m not in favor of a workaround, we need to fix this so the missing MPL headers are all installed.
The long term fix is probably figure out why the headers target is not built first before process_jam_log (I described my theory in another reply) and fix it. This will probably require attention of the Boost.Build team.
So the header target is being built, it just installs significantly less than the full set of MPL headers. You can replicate this by: 0) rm -f bin* boost 1) cd tools/regression/build 2) b2 -q 3) notice that this directory is missing: boost/mpl/aux_/preprocessed If we can get boost/mpl/aux_/preprocessed installed, I think that’s the preferable fix.
On Monday 15 September 2014 15:30:26 Belcourt, Kenneth wrote:
On Sep 15, 2014, at 9:17 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Monday 15 September 2014 14:15:48 Belcourt, Kenneth wrote:
On Sep 14, 2014, at 1:46 AM, Andrey Semashev <andrey.semashev@gmail.com>
I think I know why it worked before. Before the change the boost/mpl directory was a link to libs/mpl/include/boost/mpl. The link was created due to a dependency on some public MPL header, but it 'installed' all MPL headers, including those that were not discovered by Boost.Build due to preprocessor tricks. Now every file in boost/mpl is a link, and the problem appears on the surface.
Yes, that does sound like the issue. So, what do you think we should do about it?
As I suggested in another reply, I think we should add 'b2 headers' to the testing scripts as a hotfix. I'd create a pull request, but I have no idea how the testing works and where this command should be added.
I‘m not in favor of a workaround, we need to fix this so the missing MPL headers are all installed.
You sounded like we needed a solution ASAP. This is the quickest way to fix it that I know.
The long term fix is probably figure out why the headers target is not built first before process_jam_log (I described my theory in another reply) and fix it. This will probably require attention of the Boost.Build team.
So the header target is being built, it just installs significantly less than the full set of MPL headers.
I'm not a Boost.Build expert, but since 'b2 headers' does the right thing and building the regression tools does not, I'd say that headers target is not invoked in the second case.
You can replicate this by:
0) rm -f bin* boost 1) cd tools/regression/build 2) b2 -q 3) notice that this directory is missing: boost/mpl/aux_/preprocessed
If we can get boost/mpl/aux_/preprocessed installed, I think that’s the preferable fix.
I'll try a few experiments with Boost.Build to see if I can invoke the headers target prior to the testing tools.
On Monday 15 September 2014 19:53:39 you wrote:
On Monday 15 September 2014 15:30:26 Belcourt, Kenneth wrote:
You can replicate this by:
0) rm -f bin* boost 1) cd tools/regression/build 2) b2 -q 3) notice that this directory is missing: boost/mpl/aux_/preprocessed
If we can get boost/mpl/aux_/preprocessed installed, I think that’s the preferable fix.
I'll try a few experiments with Boost.Build to see if I can invoke the headers target prior to the testing tools.
https://github.com/boostorg/boost/pull/39 With these changes the headers target is properly invoked for me.
On Sep 15, 2014, at 9:53 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Monday 15 September 2014 15:30:26 Belcourt, Kenneth wrote:
On Sep 15, 2014, at 9:17 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Monday 15 September 2014 14:15:48 Belcourt, Kenneth wrote:
On Sep 14, 2014, at 1:46 AM, Andrey Semashev <andrey.semashev@gmail.com>
I think I know why it worked before. Before the change the boost/mpl directory was a link to libs/mpl/include/boost/mpl. The link was created due to a dependency on some public MPL header, but it 'installed' all MPL headers, including those that were not discovered by Boost.Build due to preprocessor tricks. Now every file in boost/mpl is a link, and the problem appears on the surface.
Yes, that does sound like the issue. So, what do you think we should do about it?
As I suggested in another reply, I think we should add 'b2 headers' to the testing scripts as a hotfix. I'd create a pull request, but I have no idea how the testing works and where this command should be added.
I‘m not in favor of a workaround, we need to fix this so the missing MPL headers are all installed.
You sounded like we needed a solution ASAP. This is the quickest way to fix it that I know.
The long term fix is probably figure out why the headers target is not built first before process_jam_log (I described my theory in another reply) and fix it. This will probably require attention of the Boost.Build team.
So the header target is being built, it just installs significantly less than the full set of MPL headers.
I'm not a Boost.Build expert, but since 'b2 headers' does the right thing and building the regression tools does not, I'd say that headers target is not invoked in the second case.
You can replicate this by:
0) rm -f bin* boost 1) cd tools/regression/build 2) b2 -q 3) notice that this directory is missing: boost/mpl/aux_/preprocessed
If we can get boost/mpl/aux_/preprocessed installed, I think that’s the preferable fix.
I'll try a few experiments with Boost.Build to see if I can invoke the headers target prior to the testing tools.
Finally had some time to take a closer look at this. So I was wrong, the Sandia develop Linux testers do remove the previous boost install meaning it correctly installs all the headers on those testers. This means that the implicit dependency rule works okay on Linux, and also means that it’s broken somehow on Darwin, QNX, and Windows (except for the newer gcc-mingw versions). So I think your changes that we pushed are actually okay, and we seem to have exposed a Boost Build problem with the implicit dependency rule. <implicit-dependency>/boost//headers We may need help from BB guys to track this down.
On Wed, Sep 17, 2014 at 7:33 AM, Belcourt, Kenneth <kbelco@sandia.gov> wrote:
Finally had some time to take a closer look at this. So I was wrong, the Sandia develop Linux testers do remove the previous boost install meaning it correctly installs all the headers on those testers. This means that the implicit dependency rule works okay on Linux, and also means that it’s broken somehow on Darwin, QNX, and Windows (except for the newer gcc-mingw versions). So I think your changes that we pushed are actually okay, and we seem to have exposed a Boost Build problem with the implicit dependency rule.
<implicit-dependency>/boost//headers
We may need help from BB guys to track this down.
Did you try my pull request? BTW, I did reproduce the problem according to your steps, and I was doing it on Linux.
participants (3)
-
Andrey Semashev -
Belcourt, Kenneth -
Vicente J. Botet Escriba