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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-09-16 08:30:19

On Thursday 15 September 2005 01:31, Andrey Melnikov wrote:

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

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

> >>EXPLICIT LIBRARY TARGETS
> >
> > You can write down this list, or you can GLOB
> > for libraries, or maybe something else.
>
> I tried to path.glob. The main problem is that Win32 file names aren't
> case sensitive and there's no standard/normative capitalization for
> library names. So I'd like to have target names lowercased. For now you
> have to write /win32//User32 because in my version the file name is
> capitalized this way. Is there any way to convert paths/strings to the
> lower character case?

Yes:

local names = Foo ;
names = $(name:L) ;

> >>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.
>
> In order to build something, you need to configure:
> - toolset to be used (msvc-7.0, msvc-7.1, msvc-8.0, borland ...)
> - toolset location
> - the stdlib to be used (it may be possible to use msvc-8.0 with older
> runtimes, with alternative runtimes from other toolsets, with StlPort
> instead of the built-in library, or with libctiny or similar projects,
> or even without a runtime like in case of NT kernel mode code)
> - the platform sdk to be used
> - other libraries and library collections to be used like
> /site-config//zlib, /boost//filesystem
>
> We need to provide (or continue to provide) good defaults when it's
> possible, and abilities to override the defaults at different levels if
> it's possible and a demand exists: site level, user level, project
> level, target level, command line...
>
> Is it possible to provide means to configure /win32// and /stdlib//
> projects like we do with toolsets now? 

I think yes, provided that somebody writes appropriate win32.jam and 
stdlib.jam

> The configuration should be 
> per-toolset-version or even at finer levels of granularity.
>
> 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.

> Will it 
> possible to specify stdlib versions like "static multithreaded" using
> the current feature names?
>
> > By folder search order, you mean that PSDK includes should be
> > before system ones?
>
> This problem exists only if we continue to use vcvars scripts and an
> external PSDK is used. In this case the external PSDK includes should be
> before the built-in PSDK includes. The CRT includes aren't affected in
> most cases.

Ok.

> >>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 ;-)

> >>Will targets.main-target-alternative and a custom
> >>target class help?
> >
> > I don't yet understand the problem you have, can you explain.
>
> Look how stlport.jam computes its usage-requirements. Is it better than
> I have now?

It's neither better, nor worse. For STLPort, usage requirements very much 
depend on build properties, so using target class I can express this easily. 
Otherwise, I'd have to create many alternatives for the stlport target and 
that would be harder to get right. If there's just single set of usage 
requirements, declaring a target is fine.

- Volodya

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