Re: [BBv2] Some questions

From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-07-19 08:36:55

"pal.tw" <pal.tw_at_[hidden]> writes:

> --- In jamboost_at_[hidden], Vladimir Prus <ghost_at_c...> wrote:
>> I think 
>> 
>> SOURCE_FILES = [ GLOB $(SOURCE_ROOT)/jp2/src/libjasper/
> $(SOURCE_FILES) : 
>> *.c ] ;
>> SOURCE_FILES = [ MATCH .*(jp2/src/libjasper/.*) : 
> $(SOURCE_FILES) ] ;
>> 
>> will work just fine. The "path" module is mostly used for internal 
> purposes 
>> and all paths specified by the user can be in the native format.
>
> I have done it at first. But the result of the "GLOB" rule is
> ----------------------------------------------------------------------
> D:\Programming\build>bjam
> D:\Programming\Source\ImageMagick-5.5.7\jp2\src\libjasper\jp2
> \jp2_cod.c D:\Progr
> amming\Source\ImageMagick-5.5.7\jp2\src\libjasper\jp2\jp2_dec.c ...
> ----------------------------------------------------------------------
> It turn the separators from slashes into backslashes. 
> So the following 'MATCH' invocation will not work and
> return an empty list. I want the separator be a slash
> becase of the sytax of target identifier, so that
> I can feed the main-target rules with them.

You can forward-slashify any variable with 

$(variable:T)

>
> Another thing ...
> "rule make-NT ( native ) ;" will prefix a slash to
> the path name with a dirver letter. like this...
> ----------------------------------------------------------------------
> D:\Programming\build>bjam
> /D:/Programming/Source/ImageMagick-
> 5.5.7/jp2/src/libjasper/jp2/jp2_cod.c /D:/Pro
> gramming/Source/ImageMagick-5.5.7/jp2/src/libjasper/jp2/jp2_dec.c ...
> ----------------------------------------------------------------------
> Is it the exact result you want? Or just an accident.
> I just want to make sure it will not go very far wrong
> in some condtions.

Not that I have ever agreed with this approach, but, just so you
understand it: all path manipulations in BBv2 are done in terms of
"normalized" path representations. Any time you are handling a
"native" path you are expected to normalize it by calling path.make.
path.make-NT is a helper for path.make, whose job is to take an
NT-native path and turn it into a normalized internal representation.
The leading slash is intended; all rooted paths are normalized to
begin with a slash.

>> > I tried to trace the [BBv2] code for a while, but I was lost
>> > in these codes. They are too hard to understand without more
>> > documents. ~_~
>> 
>> I understand that. I've actually started working on architecture
>> document, though it's not ready yet.
>
> Thanks. It will be helpful to us, and could attract more people to
> improve Boost Build System.
>
>> Running vcvars32.bat unconditionally was the simplest solution.
>> Otherwise, we would have to guess if vcvars32.bat was run, if it
>> was run for the same installation that we're about to use, and so
>> on.
>
> First, I must apologize for my carelessness. In Message 4187,
> I answer Mr. David Abrahams's question that the SDK doesn't
> ship with its own setup script. But later I found it -- 
> "SetEnv.bat" just in the install directory of SDK.
> Therefore I can invoke "SetEnv.bat" after "vcvars32.bat"

Cool!

> I agree with you on the point of view. But there is no information
> about where they are installed. The exact information is in
> Windows Registry.
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MicrosoftSDK\Directories]
> "Install Dir"="D:\\Program Files\\Microsoft SDK"
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\6.0]
> "InstallDir"="C:\\Program Files\\Microsoft Visual 
> Studio\\Common\\IDE\\IDE98"
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\6.1]
> ...
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.0]
> ...
>
> So I have a fantastic idea that if it is possible to add
> some built-in rules to access OS's data warehouse. 

One of the major Perforce Jam developers has developed extensions
which do exactly that. I'd be happy to have them in the Boost.Jam
source base. You might ask about these on Perforce's "jamming" list.

> I have read "Boost Build Development Plan". Now the development
> of [BBv2] should be in Milestone 6. It means that you start to
> optimize [BBv2], don't you?
>
> I have some idea. Maybe it is impracticable.
> Is it possible to transfer some implementation of [BBv2] Design,
> like "class" and "instance" concepts, to "Bjam" tool and
> make them being built-in rules. I suppose that will not only
> speed up the build process, but also keep [BBv2] more clean.

Any code we have to maintain which requires recompiling bjam is
problematic: it slows down the development process for us and causes
glitches for users, who don't expect to recompile bjam every day.
Therefore, we are extremely circumspect about writing any of BBv2 in
'C'. We do plan to do it as neccessary based on profiling
information, but only as neccessary. Certainly 'class' and 'instance'
would be low on the list of things that are desirable to move into
'C'.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com