Re: [jamboost] [BBv2] A new MS Platform SDK/StdLib selection method

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-09-14 10:16:39

On Friday 09 September 2005 10:35, Andrey Melnikov wrote:

> > - Should we have a common way to set INCLUDE, LIB, PATH and
> > potentially other environment variables as basis for implementation of
> > SDK-related functionality.
>
> What is "an SDK"? Is it more than just a library/collection of
> libraries? What other SDKs do we have? Should we have STL and Platform
> SDK handled the same way? How should we specify different Platform SDK
> configurations? Should we use features or projects?
>
> Look at my very basic proof-of-concept project. It illustrates one
> possible way of defining platform SDK just as a plain library/BB
> project. The proof is only partial, a lot of issues has to be addressed.
>
> The advantage is that the PSDK module is toolset-independent. It just
> defines usage-requirements as any other library. Also .bat setup scripts
> are avoided, and we won't need a shell if we will be able to set the
> environment from Jam.
>
> What is your general impression? Is this decoupling approach promising?
> Is it better than we have now, or worse?

If you can manage to make everything work using this approach, that would be 
best. msvc.jam is the most complicated toolset we have, so keeping complexity 
out of it is nice. Further, I don't know much about those PSDKs, but is it 
possible to use one with borland compiler? In that case, standalone module is
much better.

> Current problems:
>
> DEPENDENCY ON THE STANDARD LIBRARY
>
> Platform SDK requires the standard library to be set up. Even if CRT
> isn't used (like in my example), standard C headers should still be in
> the header search path.
>
> I hard-coded the path into win32.jam, but the idea is that the CRT will
> be described as another BB project and dependency on //stdlib/stdlib
> will be added to the win32 usage-requirements.

Why it's not reasonable to assume that compiler can find its CRT headers 
already? After all, it's true for all existing toolsets.

> EXPLICIT LIBRARY TARGETS
>
> At the moment I have to specify 174 lines like
>
> lib user32 ;
> lib kernel32 ;
> ...
>
> in win32.jam. Is it possible just to glob in the SDK libary and define
> these targets in a loop? Or is it possible just to specify a library
> name in a Jamfile and pass it to the linker as is? Is it possible to
> locate a library in <library-path> and create a BB target on the fly, so
> dependencies on such implicit libraries will be tracked? What is the
> purpose of SEARCHED_LIB target type?

The SEARCHED_LIB target type is what's created when you build

lib user32 ;

so it's not going to help with reducing the number of lines. There are two 
problems:

1. Getting the list of all those libraries.
2. Declaring them.

The latter is just a loop:

for local lib in $(all-libs) { lib $(lib) ; }

The former -- I don't know ;-) You can write down this list, or you can GLOB
for libraries, or maybe something else.

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

So, in order to just build something, I need "using stdlib"? Does not seem to 
be right idea. By folder search order, you mean that PSDK includes should be 
before system ones?

> MY_INIT RULE LOOKS LIKE A HACK
>
> Are there better ways to set the usage requirements and <search> feature
> programmatically? 

1. You can remove the my_init rule and copy its body to the global level.
2. You can move entire content of the module to the 'init' rule.
3. You can set <search> feature on target:

lib foo : : <name>foo <search>whatever ;

> Will targets.main-target-alternative and a custom 
> target class help?

I don't yet understand the problem you have, can you explain.

> PROJECT.INITIALIZE
>
> Is it still required in this case?

Yes, until this call the module can't be used a project.

- Volodya

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2