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

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-09-08 15:13:51

Alexey Pakhunov wrote:
> Resending the message. The previous one did not appear in the list.
> 
> 
>>Andrey Melnikov wrote:
>>
>>
>>>This approach will give us a better control over search paths, 
>>>especially in case of Platform SDK replacement.
>>
>>
>>One note: INCLUDE and LIB should be set too because the order of 
>>directories is important in this case.

Why? <include> just adds new folders to the end of search path. Is this 
bad? How this can cause problems? I don't see differences between 
INCLUDE and -I

>>>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%
>>
>>
>>I think we should set all variables that 'vcvars32.bat' set. We should 
>>'replicate' the build environment for the compiler as precise as 
>>possible. For instance some .dll may not be found if we omit 
>>directories in the PATH. Sure it is more potential than real problem 
>>but it can happen.

Such problems will be easily seen during even basic smoke tests. Also we 
don't use and don't support neither win32.mak nor .Net MC++.

If we don't see problems, why to overengineer the startup code?

>>>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.
>>
>>
>>I agree with you that such an approach will give us much more 
>>flexibility. The only reason why I don't like this idea is that we 
>>will need to reimplement functionality 'vcvars32.bat' for all versions 
>>of VS we support now. Once we do it it will be easy to add support of 
>>future versions.

Switching to this new approach with <include> can actually *save* us 
some work because we are implementing psdk this way anyways.

We change the toolset a lot. We'll test it on all supported platforms 
anyways. So at this point we can afford it.

When psdk is done, the only things we should add to support the rest of 
the versions are several search path constants for each version.

Andrey