Boost logo

Boost-Build :

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-09-02 04:11:47

Alexey Pakhunov wrote:

> 8. VC8 vcvarsall.bat stuff to enable cross-platform and
> non-cross-platform compilation for amd64/EM-64T and Itanium/IA-64
> 9. interactions between platformsdk module and toolsets
> 10. manual generation of environment setup script for
> <msplatformsdk>external configuration
> 12. migration to the CONFIG_COMMAND framework
> 14. a trick to export environment variables from cmd into sh
> 15. single vsvars.bat run for link and mt on VC8
All these changes are related to *.bat setup scripts we run. The code to
make them working as expected becomes more and more complicated. Do we
really need them? Will it be easier just to modify PATH manually and
specify header and library search path using usage requirements like
<include> and <library-path>?

This approach will give us a better control over search paths,
especially in case of Platform SDK replacement.

Platform SDK, C Runtime Library, STL, ATL, MFC are just libraries. It
isn't absolutely necessary to treat them specially. Theoretically, we
can just use a single setup command (for VC8):

set PATH=%BASE%\Common7\IDE;%PATH%

The rest of vcvars.bat job can be done using the
compute-usage-requirements framework and by specifying the tool paths

As the attachment illustrate, VC can generate working code without any
headers or libraries, even without C Runtime. Also note the very minimal

Of course such a usage is pretty useless because it's impossible for a
process to interact with outer world. If we remove /NODEFAULTLIB switch,
we'll need to specify a path to C Runtime dlls. Also
/ENTRY:_defaultCrtStartup will be used by default. This function
implemented by CRT then calls main() or winmain()

Though I don't know any complete replacements for Microsoft C Runtime,
the LibcTiny project can be used in some simple cases instead of the
standard library. Also it should be possible to use msvcrt.dll with
newer compilers and reduce the distributable size because this library
is present everywhere unlike the msvcr80.dll

Such approaches are tricky and maybe don't have a big practical usage in
case or CRT, but the STL and Platform SDK are often replaced, especially
in the vc6 world.

The STL library is already replaced using features. We can use the same
approach across the other standard libraries too.

What do you think? Is this feasible? Will this be be better than all the
mess we are going to get with our current approach? Remember, we are
going to implement setenv.cmd functions manually for the Platform SDK.

 --------------020009060907060101010009 Content-Type: application/x-zip-compressed;
Content-Transfer-Encoding: base64
Content-Disposition: inline;

[Attachment content not displayed.] --------------020009060907060101010009--

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at