[Gtk-sharp-list] Migrating to CMake?

[Jaroslav Šmíd]

Mike Kestner wrote:
> On Sat, 2008-10-11 at 17:00 +0200, Christian Hoff wrote:
>
>    
>>> cygwin is a obsolete tool. The future is mingw. I use atotools in
>>> mingw, but auto* really suck in windows or linux.
>>>        
>
> I'm not really interested in the old auto* sucks debate.  It does and it
> doesn't.  I have a love/hate relationship with it.  As far as cygwin
> being obsolete, I don't really care whether people use cygwin or mingw
> or whatever.  The point is that there are auto* toolchains available on
> win32 and they work.
>
>    
>> The question for me is not how much time it takes to install Cygwin;
>> Cygwin simply hides the aspect that this build system is not portable.
>> Without Cygwin there would be no way to compile Gtk# with the existing
>> build system.
>>      
>
> The build system is portable.  I don't understand why you contend it
> isn't when the toolchain is available on linux, win32, and mac
> platforms.  If by unsupported you mean it has to be downloaded and
> installed, are you arguing that the .Net SDK is unsupported on win32?
>
>    
>> I will look into both CMake and waf and see if I manage to build Gtk#
>> with them. By now I haven't got an idea how they work, but in every case
>> I don't think that the auto* build system is the best choice. I'll keep
>> you posted.
>>      
>
> Either of these would have to produce some tangible benefit to the
> project over what the auto* build does now in order for me to consider
> switching from the standard build environment on the primary development
> platform of the project.  I haven't heard anything so far that leads me
> to believe that's the case.
>
>    
Actually, both cmake and autotools have bad support for mingw-w64 on 
Win64. MSys and cygwin are problematic to install/configure on win64 - 
they don't work without additional procedures done. Even win64 developer 
of Gtk+ (what's his name?) is using custom build scripts for win64 port 
of Gtk+, because autotools just don't work correctly on win64. For 
cmake, you must rename e.g. x86_64-pc-mingw32-gcc to gcc in order to be 
found by it. After many years win64 is here, only a few developers 
aren't lazy to create or support win64 ports. There is no difficulty 
with it. Simple recompiling application suffice to have win64 port (of 
course _correct_ use of WinAPI is required to accomplish it, programs 
where pointers are typecasted to long or event int are not worth using 
and mr programmer should really consider learning again how to 
programme. Windows is not the only platform where long is 32bit on 
win64. There are standards and 32bit long on 64bit os is part of them. 
It is Microsoft's free choice to choose it, same as on it is chosen to 
be 64bit on 64bit linux.)