[Python-Dev] Evaluated cmake as an autoconf replacement
lists at cheimes.de
Mon Mar 30 20:34:21 CEST 2009
Alexander Neundorf wrote:
> This of course depends on the definition of "as good as" ;-)
> Well, I have met Windows-only developers which use CMake because it is
> able to generate project files for different versions of Visual
> Studio, and praise it for that.
So far I haven't heard any complains about or feature requests for the
project files. ;) Most Windows related issue where about the SxS
assembly issues with the new MSVCRT library.
The multitude of project files formats are an issue for most open source
libraries. Each minor version of Python has only one supported version
of Visual Studio due to possible issues with mixed MSVCRTs. 99% of all
Windows users are using the official MSI package provided by Martin. We
also have project files for VS 6.0, 7.1 and 8.0 in the PC/ subdirectory.
The VS 8.0 are created from the VS 9.0 project files. The remaining
projects are maintained manually.
>> The VS project files support debug, non debug and profile guided
>> optimization builds for X86 and AMD64 including cross compilation of
>> AMD64 binaries.
> CMake supports different build configurations.
Does it support all eight build configurations? (Debug, Release, PGO
instrument, PGO update for X86 and X64)
> No idea. Maybe it wouldn't be necessary ? With CMake you can just
> generate different buildtrees with different options, so you can get
> different behaviour in these trees.
I don't know, too.
> That's right. Is there actually a real reason for this ?
> When I posted the cmake files for python in 2007 I think they also
> worked for Windows,, but I didn't test this that much.
As far as I remember DLL take considerable more time to load than shared
libraries on Unix OSes. The VS project driven build also makes it
possible to cross compile builds for Itanium and AMD64 platforms on a
X86 Windows. Distutils doesn't support cross compilation so far.
You have to ask Martin von Löwis and Mark Hammond for detailed information.
>> In my opinion any change to an automated system is a waste of precious
>> developer times and makes our Windows support worse.
> Seriously, I don't think so.
> In KDE, our (small group of) Windows developers are the ones which
> appreciate CMake most.
> At Kitware, support for Windows and MSVC is a primary feature of
> CMake, not an afterthought.
Please understand my previous mail in the context of Python core
development. For KDE it makes perfectly sense to use cmake.
For Python on Windows I just don't see any relevant benefits. I'm not
against a CMake approach if somebody else is able to pull it off. So +0
More information about the Python-Dev