|
Boost : |
From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-04 08:20:25
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk