[Gtk-sharp-list] Migrating to CMake?

["Andrés G. Aragoneses"]

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.
> 

Here goes my 2cents:

As well as it's happening with all kinds of technologies (for example
managed VS. unmanaged applications), the layers of abstractions have to
continue growing, even in build systems.

So, the argument should not be "cross-platform" but:

- Not "awkward" build system, in the sense that it should work in the
same way regardless of the OS used (so it's better a scenario in which
you have to install the same dependency in all platforms instead of
different dependencies depending on the underlying OS).
- More maintainable. Each shell system has its own wierd syntaxes. I've
been maintaining in the past a sort-of auto-tools build system but with
Win32-shell syntax, and, as well as it woudn't have been interesting to
make a Linux-layer that abstracts this syntax in order to make it build
outside Win32, it's not interesting to always use the inverse solution:
Cygwin/MinGW/whatever. We need to abstract all platform-dependant parts
into higher level of abstraction bits, as well as Mono has done in the
development scenario, in order to let developers from all platforms
share and reuse knowledge.
- Moving from AutoTools to other system also provides an additional
advantage if the target system is supported out-of-the-box in an IDE.
Suddendly we will start attracting all those VS developers or
drag-and-drop programming lovers ;) - or command-line haters (I consider
myself a mixture of both).

Yes, these 3 reasons may not contain too much technical arguments, but
all of them target to a common concept: easier to use and maintain. A
key concept to attract contributors.

So I would advocate the mentioned tools depending on the advantages they
provide:
- CMake: already used by KDE community. Would avoid reinventing the
wheel and using a common tool, which I think it's always good
(especially for this freedesktop.org common projects that start to
arise; yeah, I've not forgotten am on gtk# list...), because of
knowledge reuse.
- MSBuild: JPryor makes a good point for advocating this one. The
circular dependency is not only addressed by xbuild but also the
"mdtool" tool.
- Waf: seems to have a showstopper for being considered as the
ready-to-go Gnome solution, and a fork is not worth it IMO.


I understand also the points of the maintainer because for him it
doesn't suppose an advantage, as his native platform is Linux and he
would have to learn a new project. This is like the VCS-to-DVCS
discussion... It will take time until everybody migrate...

Regards,

	Andrés

--