Re: [BBv2] Some questions

From: pal.tw (pal.tw_at_[hidden])
Date: 2003-07-19 01:28:19

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

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.

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

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. In the past,
OS uses environment variables to provide some information,
but today the environment-variable mechanism may not deal with
more and more information, especially there are more complicated
relationships among them. And I suppose that there will be
more and more OSes having their own data warehouses to manage
such information.

> 
> Is it possible to specify SDK include/lib path via command line 
switches to 
> the compiler. I guess they take precedence over environment?

Yes, but another problem. It seems no way to set default values in
"site-config.jam" or "user-config.jam". I must add them in every 
project. 
And it seems not be a convenient way...

> Why is it necessary to adjuast PATH?

Because Microsoft provides some useful tools, such as
MC.exe (message compiler), RC.exe (resource compiler),
SignCode.exe ...etc. They can also be used in the build process
and should be later than the ones shipped with the msvc.

> That's certainly the direction to go with toolset. Initially, we 
could create 
> os-specific modules and then further refine them with computer 
architecture, 
> or os variant and so on. We should really try to keep V2 toolsets 
are clean 
> as possible.

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.