[BBv2] A new MS Platform SDK/StdLib selection method - v2

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-09-14 16:31:48

Vladimir Prus wrote:
> On Friday 09 September 2005 10:35, Andrey Melnikov wrote:
> 
>>Current problems:
>>
>>DEPENDENCY ON THE STANDARD LIBRARY
>>
>>Platform SDK requires the standard library to be set up. Even if CRT
>>isn't used (like in my example), standard C headers should still be in
>>the header search path.
>>
>>I hard-coded the path into win32.jam, but the idea is that the CRT will
>>be described as another BB project and dependency on //stdlib/stdlib
>>will be added to the win32 usage-requirements.
> 
> 
> Why it's not reasonable to assume that compiler can find its CRT headers 
> already? After all, it's true for all existing toolsets.

MSVC and Borland (and I bet many other compilers) don't know where to 
search for the runtime until we (or vcvars.bat) set the search paths 
explicitly.

Borland and MSVC (in case of external PSDK) don't have a setup script, 
so we have to specify the paths manually.

I think that

flags borland.compile STDHDRS $(condition) : $(root)/include/ ;

is rather ugly and an ability just to set

<include>$(root)/include/ ;

would be much better.

>>EXPLICIT LIBRARY TARGETS
>>
> You can write down this list, or you can GLOB
> for libraries, or maybe something else.

I tried to path.glob. The main problem is that Win32 file names aren't 
case sensitive and there's no standard/normative capitalization for 
library names. So I'd like to have target names lowercased. For now you 
have to write /win32//User32 because in my version the file name is 
capitalized this way. Is there any way to convert paths/strings to the 
lower character case?

>>TOOLSETS SHOULDN'T SPECIFY A CRT OR A PSDK SEARCH PATH
>>
>>With this approach, a toolset shouldn't set crt or PSDK search paths on
>>its own to avoid conflicts caused by dependency on folder search order.
>>All configuration should be performed in "using stdlib" rule in
>>user-config file.
> 
> 
> So, in order to just build something, I need "using stdlib"? Does not seem to 
> be right idea.

In order to build something, you need to configure:
- toolset to be used (msvc-7.0, msvc-7.1, msvc-8.0, borland ...)
- toolset location
- the stdlib to be used (it may be possible to use msvc-8.0 with older 
runtimes, with alternative runtimes from other toolsets, with StlPort 
instead of the built-in library, or with libctiny or similar projects, 
or even without a runtime like in case of NT kernel mode code)
- the platform sdk to be used
- other libraries and library collections to be used like 
/site-config//zlib, /boost//filesystem

We need to provide (or continue to provide) good defaults when it's 
possible, and abilities to override the defaults at different levels if 
it's possible and a demand exists: site level, user level, project 
level, target level, command line...

Is it possible to provide means to configure /win32// and /stdlib// 
projects like we do with toolsets now? The configuration should be 
per-toolset-version or even at finer levels of granularity.

Is it possible to add default dependencies on /stdlib//stdlib ? Will it 
possible to specify stdlib versions like "static multithreaded" using 
the current feature names?

> By folder search order, you mean that PSDK includes should be 
> before system ones?

This problem exists only if we continue to use vcvars scripts and an 
external PSDK is used. In this case the external PSDK includes should be 
before the built-in PSDK includes. The CRT includes aren't affected in 
most cases.

>>MY_INIT RULE LOOKS LIKE A HACK
>>
>>Are there better ways to set the usage requirements and <search> feature
>>programmatically? 
> 
> 
> 3. You can set <search> feature on target:
> 
> lib foo : : <name>foo <search>whatever ;

I can specify usage-requirements on a target too. So I was able to move 
everything into win32.init.

It's a pity that path.basename doesn't support list operations, and I 
have to use a loop. Is it a good idea to add such support?

>>Will targets.main-target-alternative and a custom 
>>target class help?
> 
> 
> I don't yet understand the problem you have, can you explain.

Look how stlport.jam computes its usage-requirements. Is it better than 
I have now?

Andrey
 --------------080201070501080506010005 Content-Type: application/octet-stream;
name="minibuild_v2.rar"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="minibuild_v2.rar"

[Attachment content not displayed.] --------------080201070501080506010005--