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

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-09-15 07:09:24

Reece Dunn wrote:
> Andrey Melnikov wrote:
> 
>>Reece Dunn wrote:
>>
>>
>>>In general, on Windows, an "SDK" has the 
>>>following layout:
>>>
>>> <sdk-root>
>>> include -- header files
>>> src -- source code
>>> lib -- libraries
>>> bin -- binaries (executables and shared libraries)
>>>
>>>I am not sure how strictly this structure holds for other "SDK"s. I am 
>>>thinking of things like python. Also, do "SDK"s follow a different 
>>>convention on *nix?
>>
>>The convention is weak. It's often ignored. There are a lot of 
>>exceptions. Boost itself, for example.
> 
> 
> This is where you'd have the ability to set these directories, but use 
> those (or more suitable ones) as defaluts. For example:
> 
> using atlmfc : 7.0 : path2atlmfc ; # default layout
> 
> using atlmfc : 7.0 : path2atlmfc # custom layout...
> :
> <include-dir>inc # header files = path2atlmfc/inc
> <library-dir>libs # libraries = path2atlmfc/libs
> <binary-dir>binary # binaries = path2atlmfc/binary
> ;

Good idea. I'd like to see the same configuration means for stdlib, 
platform SDK and other libraries like Boost.

How you are going to specify that your project includes atlmfc 7.0 
headers and links with an MFC dll? "using" just configures atl-7.0. It 
doesn't specify the dependency and it doesn't add usage-requirements.

>>>Hmm... are there <system-include> and <system-library> features? 
>>
>>Yes. There is at least <sysinclude>. But it isn't widely supported by 
>>toolsets.
> 
> 
> A <syslibrary> option would be useful as well. Default behaviour could 
> be used for toolsets that don't support <sys***> explicitly.
> 
> 
>>Also, should Boost support this version/path syntax to configure which 
>>of the installed Boost versions is to be used?
> 
> 
> Hmmm... interesting.

ATL, MFC, Standard Library, Boost, Zlib are just libraries. So they 
should be handled in a unified way.

>>>If 
>>>there were, we could then add them to the environment for msvc and do 
>>>the right thing with other compilers (doesn't CodeWarrior have a system 
>>>include option?) 
>>
>>MSVC itself doesn't have a separate system include option. Only VS IDE 
>>has. I wonder if there are any compilers with such separate option.
> 
> 
> What I was meaning is that for VC, you would have
> 
> action msvc.compile.c++
> {
> set INCLUDE=$(SYSINCLUDE)
> set LIB=$(SYSLIBRARY)
> $(.CC) ...
> }
> 
> so, setting the system environment variables *is* the VC system 
> include/library option!
> 
Well, the INCLUDE and LIB variables work exactly the same way as -I and 
/LIBPATH: command line switches.

IMO "system include" term means

#include <file.h>

and

"include" term means

#include "file.h"

And <sysinclude> feature is for the compilers that have separate search 
paths for #include "" and #include <>.

Andrey