Intel toolset / library names
I've just found out that there is still something wrong with the intel configurations (also in 1.32). The libraries (I build them using bjam stage) have the name "....iw81...lib" but the names referred to by auto link are "...iw...lib". One has to rename them manually. I got the feeling that the Intel toolsets should undergo a substantial review anyway; I hope I've enough time to do that one day (any other volunteers?? :) ) Stefan
I've just found out that there is still something wrong with the intel configurations (also in 1.32). The libraries (I build them using bjam stage) have the name "....iw81...lib" but the names referred to by auto link are "...iw...lib". One has to rename them manually.
The problem is that there are a multitude of inconsistently named Intel toolsets, if you build with intel-win32-tools.jam then auto-linking will work, but if you build with one of the "versioned" toolsets then it won't. I hope that bbv2 will adopt a saner naming convention for libraries (if there is one of course). John.
John Maddock wrote:
I've just found out that there is still something wrong with the intel configurations (also in 1.32). The libraries (I build them using bjam stage) have the name "....iw81...lib" but the names referred to by auto link are "...iw...lib". One has to rename them manually.
The problem is that there are a multitude of inconsistently named Intel toolsets, if you build with intel-win32-tools.jam then auto-linking will work, but if you build with one of the "versioned" toolsets then it won't. I hope that bbv2 will adopt a saner naming convention for libraries (if there is one of course).
Could you elaborate? I happen to work on precisely that at the moment. The current behaviour is pretty similar to V1. You get one path component for base toolset ("iw") and one path component for version ("8.0", "8.1", you name it). The only difference from V1 is that there's only one toolset description file, and versions are specified in user's 'user-config.jam'. If you can say what changes to the scheme are necessary, I sure they can be quickly implemented. - Volodya
Vladimir Prus wrote:
Could you elaborate? I happen to work on precisely that at the moment. The current behaviour is pretty similar to V1. You get one path component for base toolset ("iw") and one path component for version ("8.0", "8.1", you name it). The only difference from V1 is that there's only one toolset description file, and versions are specified in user's 'user-config.jam'.
The main problem I see is that there are two compilers involved each of which has to be configured. In theory it's possible to combine each version of Intel compiler 6-8 with each version of VC 6-7.1. These sets create dependencies that are not handled perfectly at the moment IMO. Furthermore, (when the other problems are solved) there should also be a toolset for Intel+STLPort (...which I tried to write for 1.32 but I gave up due to lack of time).
If you can say what changes to the scheme are necessary, I sure they can be quickly implemented.
I can't list many details at the moment, I've to look into it myself again. Stefan
Stefan Slapeta wrote:
Vladimir Prus wrote:
Could you elaborate? I happen to work on precisely that at the moment. The current behaviour is pretty similar to V1. You get one path component for base toolset ("iw") and one path component for version ("8.0", "8.1", you name it). The only difference from V1 is that there's only one toolset description file, and versions are specified in user's 'user-config.jam'.
The main problem I see is that there are two compilers involved each of which has to be configured. In theory it's possible to combine each version of Intel compiler 6-8 with each version of VC 6-7.1. These sets create dependencies that are not handled perfectly at the moment IMO.
This is still not enough information. In V2, you can do: using intel-win : 8.0-vc6 : : <compatibility>vc6 ; using intel-win : 8.0-vc7 : : <compatibility>vc7 ; And "8.0-vc6" and "8.0-vc7" will be the version in library name. If that version are equal to what autolinking wants, there should be no problem.
Furthermore, (when the other problems are solved) there should also be a toolset for Intel+STLPort (...which I tried to write for 1.32 but I gave up due to lack of time).
Maybe, you can start with V2? Add using intel-win ; using stlport ; to tools/build/v2/user-config.jam, go to tools/build/v2/example/hello, run, bjam intel-win stdlib=stlport and report any problem there are. Details on configuring toolsets are in comment in user-config.jam and in output of: bjam --v2 --help intel-win.init bjam --v2 --help stlport.init and at http://boost.org/boost-build2/doc/html/bbv2/advanced.html#bbv2.advanced.conf... - Volodya
Vladimir Prus wrote:
This is still not enough information. In V2, you can do:
using intel-win : 8.0-vc6 : : <compatibility>vc6 ; using intel-win : 8.0-vc7 : : <compatibility>vc7 ;
And "8.0-vc6" and "8.0-vc7" will be the version in library name. If that version are equal to what autolinking wants, there should be no problem.
Cool, I'll test that.
Maybe, you can start with V2? Add
I don't know the current plans but how realistic is shipping boost 1.33 with v2 as (main) build tool? Stefan
Stefan Slapeta wrote:
Maybe, you can start with V2? Add
I don't know the current plans but how realistic is shipping boost 1.33 with v2 as (main) build tool?
I'm close to implementing the remaining two things: installation and Boost.Python. I'm pretty sure V2 will be OK technically well before 1.33. - Volodya
using intel-win : 8.0-vc6 : : <compatibility>vc6 ; using intel-win : 8.0-vc7 : : <compatibility>vc7 ;
And "8.0-vc6" and "8.0-vc7" will be the version in library name. If that version are equal to what autolinking wants, there should be no problem.
John runs screaming from the building......! OK, so the same compiler could produce any one of: "iw" "iw-8.0" "iw-8.0-vc7" This is *impossible* to handle with auto-linking and even worse than version 1! What I really want to aim for if possible: For any given compiler, there is one and only one possible name that can be produced, and that name can be derived *entirely* from information available to the C++ preprocessor. Otherwise, I might as well just give up and rip out all of the auto-linking code, sorry! John.
John Maddock wrote:
using intel-win : 8.0-vc6 : : <compatibility>vc6 ; using intel-win : 8.0-vc7 : : <compatibility>vc7 ;
And "8.0-vc6" and "8.0-vc7" will be the version in library name. If that version are equal to what autolinking wants, there should be no problem.
John runs screaming from the building......!
OK, so the same compiler could produce any one of:
"iw" "iw-8.0" "iw-8.0-vc7"
This is *impossible* to handle with auto-linking and even worse than version 1!
Both in V1 and V2, Boost.Build user can specify any name/version for a compiler, and there's no way to prevent that. In addition, I can always make replace "cl.exe" with my own program which will invoke gcc.exe ;-) The point is: build system cannot be expected to determine toolset version automatically. I think it's reasonable to ask a person building boost to provide explicit version numbers when initializing a toolset, no? (While msvc.jam has some logic to autodetect installed version from target path, this cannot be considered 100% reliable).
What I really want to aim for if possible:
For any given compiler, there is one and only one possible name that can be produced, and that name can be derived *entirely* from information available to the C++ preprocessor.
This is only possible if build system will compile a special program with each compiler that will output that preprocessor information, and derive library name from that. This sounds pretty complicated and I don't understand why it's needed. Say, you can detect version of Intel via preprocessor code, and derive autolink names from that, say (forget about vc-mode for a moment): 8.0 -> iw-8.0 8.1 -> iw-8.1 Now, the documentation for building boost say: "When initializing toolset, the version must be specified" User writes: using intel-win : 8.0 ; using intel-win : 8.1 ; and gets the same "iw-8.0" and "iw-8.1". Is requirement to specify version that drastic? - Volodya
Vladimir Prus wrote:
John Maddock wrote:
using intel-win : 8.0-vc6 : : <compatibility>vc6 ; using intel-win : 8.0-vc7 : : <compatibility>vc7 ;
And "8.0-vc6" and "8.0-vc7" will be the version in library name. If that version are equal to what autolinking wants, there should be no problem.
John runs screaming from the building......!
OK, so the same compiler could produce any one of:
"iw" "iw-8.0" "iw-8.0-vc7"
This is *impossible* to handle with auto-linking and even worse than version 1!
Both in V1 and V2, Boost.Build user can specify any name/version for a compiler, and there's no way to prevent that. In addition, I can always make replace "cl.exe" with my own program which will invoke gcc.exe ;-) The point is: build system cannot be expected to determine toolset version automatically. I think it's reasonable to ask a person building boost to provide explicit version numbers when initializing a toolset, no? (While msvc.jam has some logic to autodetect installed version from target path, this cannot be considered 100% reliable).
Some systems invoke the tools with -v to see what they tell you about the version. It would be good to have that capability, but of course first we need someone to code up the portable popen. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Both in V1 and V2, Boost.Build user can specify any name/version for a compiler, and there's no way to prevent that. In addition, I can always make replace "cl.exe" with my own program which will invoke gcc.exe ;-) The point is: build system cannot be expected to determine toolset version automatically. I think it's reasonable to ask a person building boost to provide explicit version numbers when initializing a toolset, no? (While msvc.jam has some logic to autodetect installed version from target path, this cannot be considered 100% reliable).
Some systems invoke the tools with -v to see what they tell you about the version. It would be good to have that capability, but of course first we need someone to code up the portable popen.
Maybe, the right way is to write "configure.py" which will create user-config.jam appropriate to the current system? - Volodya
John Maddock wrote:
The problem is that there are a multitude of inconsistently named Intel toolsets,
but it's possible to fix that!
if you build with intel-win32-tools.jam then auto-linking will work, but if you build with one of the "versioned" toolsets then it won't.
intel-win32-tools.jam doesn't either. I don't know why yet.
I hope that bbv2 will adopt a saner naming convention for libraries (if there is one of course).
I'm quite sure there is, at least a better one. Stefan
participants (4)
-
David Abrahams -
John Maddock -
Stefan Slapeta -
Vladimir Prus