[jamboost] [BBv2] A bug in borland.jam, refactorings for msvc.jam and the future of minibuild

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
>>explicitly.
>>
>>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 borland.link STDLIBPATH $(condition) : $(root)/lib ;

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

-I"$(root)\Include";"$(root)\Include\vcl"
-L"$(root)\lib";"$(root)\lib\obj";"$(root)\lib\release";"$(root)\lib\PSDK"

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)
C++FLAGS += $(CFLAGS)

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.

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

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

Andrey
 --------------080503060204010508040402 Content-Type: text/plain;
name="win32.jam"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="win32.jam"

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 ;
}
 --------------080503060204010508040402--