[cmake-developers] Setting up environment using ExternalProject_Add

[James Johnston]

> -----Original Message-----
> From: cmake-developers [mailto:cmake-developers-bounces at cmake.org]
> On Behalf Of David Cole via cmake-developers
> Sent: Wednesday, August 12, 2015 15:53
> To: Brad King
> Cc: cmake-developers at cmake.org
> Subject: Re: [cmake-developers] Setting up environment using
> ExternalProject_Add
> 
> One thing to consider before embarking on modifying CMake for "required
> environment" purposes is that it might be just as simple to "force" (or at
least
> strongly encourage) your project developers to use the proper environment
> for running the whole build.
> 
> You could, for example, have an initial "external" project which all
others
> depend on which verifies the proper environment is set when it is called.
If
> not, it fails with an error, and prevents downstream bits from building.
> 
> <snip>

I think your situation is simpler than mine - i.e. if I'm reading this
right, all your ExternalProjects are built for the same Visual C++ version
and CPU architecture - such that the user can/should run VCVarsAll before
invoking the CMake superbuild?

What I'm trying to do:  A CMake superbuild that expects NO environment set
up, and NO languages configured.  It:
 * Builds Visual C++ 32-bit
 * Builds Visual C++ 64-bit
 * Builds some other non-Visual-C++ compilers/architectures

All within the same superbuild.  This is due to the fact that CMake doesn't
support multiple architectures directly (and probably won't for a long time,
if ever).  So, each ExternalProject_Add needs to have its own unique
environment set up.  I don't think it makes sense to try to run
VCVarsAll.bat before invoking the superbuild - in fact, doing so is
detrimental (i.e. increases risk of building for the wrong CPU architecture
if a particular VCVarsAll.bat invocation silently malfunctions).

Best regards,

James Johnston