Boost logo

Boost-Build :

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:
>>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

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.

> 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?

>>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.

>>Are there better ways to set the usage requirements and <search> feature
> 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?

 --------------080201070501080506010005 Content-Type: application/octet-stream;
Content-Transfer-Encoding: base64
Content-Disposition: attachment;

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

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at