Boost logo

Boost-Build :

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-09-16 17:55:36

Vladimir Prus wrote:
> On Thursday 15 September 2005 01:31, Andrey Melnikov wrote:
>>>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 don't think so. Borland has bcc32.cfg where you can add paths and that file
> will be automatically read.

It doesn't look practical to overwrite bcc32.cfg every time we want to
change the compilation options between internal and external SDKs.

At the moment borland.jam doesn't rely on bcc32 but sets the paths manually:

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

Here is the default bcc32.cfg (I replaced $(root) to improve readability):


We missed several folders. This means that it's likely that the Boost
will stop to compile if the default paths are be removed from bcc32.cfg
by a user.

So we should decide if we rely on the presense of the default paths in
the bcc32.cfg and the ilink32.cfg.

If we will rely, then we should remove the two lines completely. If we
won't, we should add the other required folders too. At the moment
things just work by accident.

>>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.
> Better for what? I should be missing something.

Using existing usage-requirements for win32 and stdlib will make the
toolsets more lightweight. Of course, the toolset-specific code won't
disappear but will just be moved to stdlib.jam or to win32.jam, but I
hope that overall amount of code will be reduced.

It seems to me that having all features translated into lower-level
features will help us to do less work during the further development of
the toolsets:

I'm thinking of something similar to feature.compose:

feature.compose <stdlib>stlport : <library>/stlport//stlport ;

I'd like to see something like

feature.compose <include> : <cflags>-I<include> ;
flags msvc.compile CFLAGS <cflags> ;

I wonder if it's feasible and will actually improve the code?

I'll try to test these concepts in the next versions of my minibuild
pilot project. Its goals are to learn BB better and to find out if there
are ways to do things better than we do now.

I don't want to change the current architecture. I even have very little
knowledge about the generators, the property sets and other internals.
But IMO the code quality outside the core can be improved. For example,
in msvc.jam we have:

actions compile.c++ bind RSP
$(.CC) /Zm800 -nologo -TP -U$(UNDEFS) $(CFLAGS) $(C++FLAGS)
$(USER_CFLAGS) @"$(RSP:W)" -c -Fo"$(<[1]:W)" && $(RM) "$(RSP)"

IMO maybe it would be better to have something like this:

CFLAGS += /Zm800 -nologo -c $(USER_CFLAGS) -U$(UNDEFS)

actions compile.c++ bind RSP
$(.CC) -TP $(C++FLAGS) -Fo"$(<[1]:W)" @"$(RSP:W)" && $(RM) "$(RSP:W)"

Now I think that such changes can be submitted right now, without a
research... Do you think it's a good idea to perform such refactorings
to reduce the code duplication?

I don't like to fix the things which aren't broken, but I think that
such changes will help us to prepare to Alexey's patches.

>>>>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.
>>Is it possible to add default dependencies on /stdlib//stdlib ?
> I don't think I know any way, yet. But probably, we can first start with
> win32, which is explicit dependency.

With win32, the situation is strange. It seems that Borland and Open
Watcom use some kind of autolinking and there's no need to specify a
dependency on user32.dll explicitly.

Now I'm trying to implement minimal MSVC, Borland and Open Watcom
toolsets to see what code can be reused by different compilers.

It looks like generators.register* calls are identical among these three
toolsets, and I'll try to create a wrapper.

BTW Open Watcom has a very poor compliance. It even doesn't support
typename keyword and template<> syntax for explicit template specialization.

>>>>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?
> I don't have an opinion ;-)

Actually I ended with an excellent $(lib:LB) one-liner (see the
attachment). Now there are no loops in win32.jam at all. I wonder if
there are ways to reduce it even more.

 --------------080503060204010508040402 Content-Type: text/plain;
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;

import project ; project.initialize $(__name__) ;

project win32 ;

rule init
import os ;

local tools = [ os.environ VS80COMNTOOLS ] ;
local root = $(tools)..\\..\\VC ;
local psdk-root = $(root)\\PlatformSDK ;
local psdk-lib = $(psdk-root)\\lib ;
local roots = $(root) $(psdk-root) ;

local libs = [ GLOB $(psdk-lib) : *.lib ] ;

lib $(libs:LB) : : : <search>$(psdk-lib) : <include>$(roots)\\include ;

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