Boost logo

Boost-Build :

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-08-01 14:16:56


Alexey Pakhunov wrote:
> Andrey Melnikov wrote:
>
>>- Recently I submitted my own bugfix-only patch (now including CVS diff)
>>which fixes some bugs in the toolset.
>
> Your changes are included into this patch.
>
>>Or to wait until first patch is
>>reviewed and incorporated, and then change the next patch properly. I
>>don't know which way is better.
>
> My patch can be submitted to CVS not sooner than M11 will be released.
> So I merge the fixes that will be checked in.
>

Now after review by Vladimir I sent a new version of my patch. So you
need to merge my changes again.

>>- new feature names and values will need to be carefully selected and
>>pass a review in order to get accepted. See my discussion about
>>precompiled headers http://article.gmane.org/gmane.comp.lib.boost.build/9602
>
> Agree.

Can anybody help us with this review?

>>I think we should reverse engineer the PSDK setvar.cmd switches and
>>check. I think that "platform" switch just #defines WINVER or something
>>like this. So built-in compiler should support it too.
>
>
> <platform> and <arch> together affect INCLUDE, LIB, PATH, CPU, APPVER
> and TARGETOS environment variables. The last three are really
> interesting. They are consumed by win32.mak which sets preprocessor
> defines and command line options in accordance to passed CPU, APPVER and
> TARGETOS.
>
> It seems we need to implement functionality of win32.mak as part of
> msvc.jam.

Is our ultimate goal to make external and built-in psdk builds using the
same set of compiler settings?

>>msvc-config is deprecated, isn't it? I think the autodetection should be
>>built into main MSVC toolset. Or we should have -config pseudo-toolsets
>>for other compilers too.
>
>
> I don't see any attempt to get rid of msvc-config.jam right now. While
> it is still exists I gathered all detection logic there. Later it will
> take 5 minutes to move all code from msvc-config.jam to msvc.jam.
>
>
Besides patch autodetection msvc-config also runs "using msvc" rule
several times for each of the autodetected versions.

Can this functionality be built into msvc.jam? Should it?

I think we should merge registry path autodetection into msvc.jam right
now. Msvc-config has a separate purpose.

Andrey

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk