[BBv2][msvc] should we avoid .bat scripts at all?

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

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

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.

Andrey
 --------------020009060907060101010009 Content-Type: application/x-zip-compressed;
name="minibuild.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="minibuild.zip"

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