[build] Running b2 with particular toolset invokes other toolsets in user-config.jam
I brought up this issue on the Boost build mailing list and it was eventually ignored, so I will bring it up here again. If I run "b2 toolset=sometoolset" Boost Build ends up invoking other toolsets in my user-config.jam along with "sometoolset" to do the build. This invoking of other toolsets seems not only a waste of time and unnecessary but also wrong in the sense that the invoking of some other toolset in user-config.jam may produce an error. I do not understand the necessity for invoking other toolsets in user-config.jam when I have specified the toolset I want. The practical situation for me which is causing problems with Boost Build behavior, because of the actions described above, is that I have a local setup under Windows where I can run many different versions of gcc/mingw or gcc/mingw64. In order to do this I using a changing symbolic link, on my PATH, to point to any one of many versions of gcc in different directories. I have a file running appropriate commands that switches between the versions. I have also built clang on Windows with a particular gcc version and therefore any invocation of clang looks for the run-time system of that particular version when clang is invoked. So if I "switch" gcc to a version which is not the one wih which i built clang, and then invoke Boost Build with that gcc toolset, clang also gets invoked as explained in the beginning remarks above, and this gives an error from the clang invocation. It is true that Boost Build continues, even after the error message coming from clang, in executing the appropriate jamfile with the particular version of gcc as the toolset. But it is annoying nonetheless to see this error for a toolset I am not even invoking. Cannot something be done in Boost Build so that if I am invoking toolset=x there should be no reason to be trying toolset=y unless it is actually needed for something when using toolset=x ? As for instance when the bjam files specifies some other tool ( doxygen, fop, xsl ) which have to be used.
AMDG On 08/26/2014 11:40 AM, Edward Diener wrote:
I brought up this issue on the Boost build mailing list and it was eventually ignored, so I will bring it up here again.
If I run "b2 toolset=sometoolset" Boost Build ends up invoking other toolsets in my user-config.jam along with "sometoolset" to do the build. This invoking of other toolsets seems not only a waste of time and unnecessary but also wrong in the sense that the invoking of some other toolset in user-config.jam may produce an error. I do not understand the necessity for invoking other toolsets in user-config.jam when I have specified the toolset I want.
Boost.Build should only build with the toolsets that you specify. (Unless a Jamfile explicitly overrides it, which shouldn't happen anywhere in Boost.) I've never encountered anything like this. In Christ, Steven Watanabe
On 8/26/2014 3:16 PM, Steven Watanabe wrote:
AMDG
On 08/26/2014 11:40 AM, Edward Diener wrote:
I brought up this issue on the Boost build mailing list and it was eventually ignored, so I will bring it up here again.
If I run "b2 toolset=sometoolset" Boost Build ends up invoking other toolsets in my user-config.jam along with "sometoolset" to do the build. This invoking of other toolsets seems not only a waste of time and unnecessary but also wrong in the sense that the invoking of some other toolset in user-config.jam may produce an error. I do not understand the necessity for invoking other toolsets in user-config.jam when I have specified the toolset I want.
Boost.Build should only build with the toolsets that you specify. (Unless a Jamfile explicitly overrides it, which shouldn't happen anywhere in Boost.) I've never encountered anything like this.
I did not mean to imply that it was building with some other toolset but that it is executing some other executables mentioned in my user-config.jam, for what reason I do not understand. I posted the result of: b2 --debug-configuration toolset=gcc-4.8.1 on the Boost Build forum after asked to do so but never heard anything further. The output shows that clang is being executed for some reason or other.
AMDG On 08/26/2014 03:23 PM, Edward Diener wrote:
I did not mean to imply that it was building with some other toolset but that it is executing some other executables mentioned in my user-config.jam, for what reason I do not understand. I posted the result of:
b2 --debug-configuration toolset=gcc-4.8.1
on the Boost Build forum after asked to do so but never heard anything further. The output shows that clang is being executed for some reason or other.
I see. That's the expected behavior. It's running clang in order to get the version number from the compiler. using clang ... ; is a function call which configures the clang toolset and it does so immediately. In Christ, Steven Watanabe
On 8/26/2014 5:43 PM, Steven Watanabe wrote:
AMDG
On 08/26/2014 03:23 PM, Edward Diener wrote:
I did not mean to imply that it was building with some other toolset but that it is executing some other executables mentioned in my user-config.jam, for what reason I do not understand. I posted the result of:
b2 --debug-configuration toolset=gcc-4.8.1
on the Boost Build forum after asked to do so but never heard anything further. The output shows that clang is being executed for some reason or other.
I see. That's the expected behavior. It's running clang in order to get the version number from the compiler. using clang ... ; is a function call which configures the clang toolset and it does so immediately.
I think it is wrong to do so immediately. If I am using the clang toolset I would understand it, but if I am not using the clang toolset I do not understand what purpose configuring the clang toolset could serve. I do understand that as far as Boost Build is concerned user-config.jam is probably just another jamfile, which follows the rules of how jam files are processed, and that this may make programming Boost Build easier. But I think an exception should be made for user-config.jam ( and probably site-config.jam also ) in that the end-user may place jam statements in it which are totally irrelevant for the particular jam file(s) being invoked and the toolset used, but which will of course be relevant in another situation. Therefore completely configuring toolsets which appear in user-config.jam, before the toolsets are specified anywhere in the jam file(s) being invoked, every time b2 is run against jam file(s) and a toolset is specified, does not seem the right way of doing things to me. Besides the local problem I encountered, described in my OP, which admittedly is very probably a rare situation, Boost Build is doing all sorts of extra processing it probably doesn't need to do the majority of the time when b2 is run, when it auomatically configures every toolset in user-config.jam which has the 'using toolset ... ' statement. I will file this as a suggestion on Trac and I hope it will be considered in Boost Build.
participants (2)
-
Edward Diener -
Steven Watanabe