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):
>>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
>>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
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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk