On Jul 26, 2010, at 3:46 PM, Olaf van der Spek wrote:
On Mon, Jul 26, 2010 at 9:21 PM, David Cole <david.c...@kitware.com>
wrote:
Olaf,
It's definitely not easy to make such a modification with the
current VS
generators. For better or for worse, there are currently separate
generators
for Visual Studio 32-bit and 64-bit projects. It would be a major
re-working
of those separate generators to combine them into a single one that
chose
the architecture at *build* time rather than at configure time.
Why are there two generators?
I don't see why the decision has to be made at another time.
Configure time is fine with me.
Many projects already have logic in their CMakeLists.txt files that
goes
something like this:
if(CMAKE_SIZEOF_VOID_P EQUAL 8)
# do 64-bit stuff at *configure* time...
else()
# 32-bit stuff
endif()
If you make *configure* time decisions based on architecture, then
it's not
easy to support multiple architectures without multiple configures.
(Multiple build trees...)
Is there a problem with multiple configures / build trees?
No, which is what is done now, just at a "higher" level than you are
wanting. You would like to have Win32 and Win64 in the same solution
file which would require multiple configure runs in the same build
directory. Currently CMake requires the developer to create 2 distinct
build trees, one for Win32 and one for Win64 where each build
directory is configured with the appropriate compiler version. So same
idea just implemented slightly differently.
Since this is a prevalent scheme that is widely used by folks
coming from
single-config, single-architecture (makefile based) build
systems... it's
the way CMake has gotten to the point it's at now. I'm not saying
this is
good or bad, just explaining that this is the way it is, and that
there are
historical reasons why we got to this point.
So.... what you're attempting is probably possible, but it's
definitely not
easy. And it will probably require some significant re-work of the
existing
code.
Let us know if you have any other specific questions that we can
answer for
you.
x64 is not a priority for me ATM.
Having static configs (static lib, static runtime and static lib,
dynamic runtime) is more important.
Olaf
It may not be a priority for _you_ but it is a requirement for
me. The code snippet that David C. put in there is extremely important
to get right and the ONLY way to get it right is to run configure
multiple times for each Arch. Just have a look at any project that
attempts to support Universal Binaries on OS X. The same problem
exists. One has to make sure that the sizes of pointers and some
primitives are correct so header file generation is correct.
_______________________________________________
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://www.cmake.org/mailman/listinfo/cmake
