Re: [jamboost] [BBv2] Some questions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-07-18 06:49:20

pal.tw wrote:

> 1. The built-in rule "GLOB" has the prototype like
> "rule GLOB ( directories + : patterns + : downcase-opt ? )",
> but [BBv2] rule "path.glob" has "rule glob ( dir : patterns + )".
> So I can't execute the following instructions successfully.
> #---------------------------------------------------------------------
> SOURCE_FILES = jp2 jpc base ;
> SOURCE_FILES =
> [ path.glob $(SOURCE_ROOT)/jp2/src/libjasper/$(SOURCE_FILES) : *.c ] ;
> SOURCE_FILES = [ MATCH .*(jp2/src/libjasper/.*) : $(SOURCE_FILES) ] ;
> #---------------------------------------------------------------------

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.

> D:\Programming\build\ImageMagick>bjam Magick
> ...patience...
> ...found 1161 targets...
> ...updating 201 targets...
> msvc.compile.c actions too long (max 2047):
[...]
> It seems that it adds all the output paths of the main-targets
> source to the include-paths. 

Yea, that's right. 

> At the other hand, the "compile"
> action doesn't use a command file since the actions would exceed
> the limit of the command shell.

While link action uses response files, the compile action does not. I think 
the idea was the compile action is not that long, usually. 
The primary problem here are extra include paths. I'm now considering an 
approach to eliminating them, so the problem might disappear soon...

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

> 3. The "msvc" toolset always use the "vcvars32.bat" file to setup
> the "msvc" environment variables, such as include-paths,
> library-paths ..etc. But no way to setup the location of
> the Platform SDK. This make me not to use the lastest system
> service released from Microsoft.
>
> Does anybody know the convenient way to setup the location
> of Platform SDK? When using "msvc" toolset, let [BBv2] search
> the location of the Platform SDK first, and then the compiler's
> location. Of course, not to modify the "msvc.jam" or
> "vcvars32.bat" files directly. ^_^

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.

Later you wrote:
> Mmm...I just set the enironment variables "INCLUDE", "LIB" ,
> and "PATH". Let the paths of SDK appear before the ones of MSVC.
> But [BBv2] always call "vcvars32.bat", it will replace
> those enironment variables. It nag me for a while.

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

> 4. I saw someone suggested separating out common rules for OS.
> Hmmm, what about common features of a platform?
> A platform, I mean, includes OS and the computer architecture,
> such as CPU type. For example, Microsoft Windows may run in
> different computer system, such as "i386", "ALPHA", "IA64",
> "ALPHA64". and there are a little different compiler and
> linker options among them.
>
> So does gcc, there are so many varints could run in so many
> platform. Some features are particular in some platform,
> and must be point out by defining some symbols or applying
> some compiler options no matter what compiler we use.
> And It may be also useful for cross-compilation.

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.

- Volodya