On Mon, 17 Sep 2012 09:57:28 -0400, Brad King wrote:
On 09/14/2012 05:59 PM, Patrick Gansterer wrote:
Maybe you can merge the first patch already.
Yes, done.
The idea of a "generator platform" is not generic among all
generators.
Rather than the general CMAKE_GENERATOR_PLATFORM infrastructure I'd
generator-specific handling. The value of -GP should be passed to
the
global generator created from -G. If the generator does not
support
platform specification in this way then -GP should be an error (all
generators except VS >= 8). If the generator does support -GP then
it
should do its own thing to save the value. For VS save it in a
cache
entry like "CMAKE_VS_PLATFORM" (we have "CMAKE_VS_PLATFORM_TOOLSET"
already for the VS 10 toolchain in some cases).
I'm not a big fan of your ideas: What about the parts where we
pass the generator platform to other parts? Do we want to add
branches for every generator type to get get correct value for
the -GP parameter (e.g. if (CMAKE_GENERATOR == "Visual Studio
...") "-GP ${CMAKE_VS_PLATFORM}")? IMHO that's not a good
idea. Also handling for making sure that generator platform
isn't changed by the user (like we do for -G already) in a
second run of CMake must be duplicated later if we add -GP to
more than one generator. (and so on...)
Good points, but we still need to reject -GP when using generators
for which it does not make sense. I think it may be moot anyway;
see below.
I realized that existing projects may test ${CMAKE_GENERATOR} to
look
for things like "Win64". For compatibility we need to make sure
that
-G "Visual Studio 10" -GP x64
results in CMAKE_GENERATOR being set to
-G "Visual Studio 10 Win64"
while processing CMake code even if it is not used that way
internally. Of course for future VS versions the generator names
will not need to work this way, only the existing ones.
Since we need to support -G "Visual Studio 10 Win64" anyway, I don't
see
much problem if such cases will work with -G "Visual Studio 10
Win64",
but not with -G "Visual Studio 10" -GP x64.
We are talking about changing the way the user selects the generator
in the GUI to be equivalent to -G/-GP. We cannot process existing
projects differently depending on how the generator was selected.
I also know there are projects that pass ${CMAKE_GENERATOR} to
internal invocations of CMake in order to say "build it like I'm
built". These paths would not work if any information moved over
to CMAKE_GENERATOR_PLATFORM or an equivalent variable.
I think the value of -GP has to be stored in CMAKE_GENERATOR at
the end of the generator name as it is now. The new option and GUI
updates are really just about simplifying the selection of the
generator and avoiding per-platform global generators in the internal
implementation. Users can either use -G and specify the full
generator name with platform or use -G/-GP separately but either way
the value of CMAKE_GENERATOR will be the same.
This can probably be improved in the future with a new cmake policy
but I don't want to open that can of worms just for WinCE. I think
you can implement -G/-GP such that the values are both stored in the
CMAKE_GENERATOR value. Internally we won't need a separate global
generator for every platform anymore, but that does not change the
public interface.
If we store everything in one variable (via string concatenation) I
don't see much value in an extra -GP switch. We need to split the
${CMAKE_GENERATOR} variable into generator+platform then all the time
anyway.
Maybe we can only change to current exact match of the generator name
to a "startsWith" and let the global generator class decide if the
generator name is valid?
-- Patrick
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers