Re: build system alternatives (Was: Using vala in GNOME)

["Alberto Ruiz" <aruiz gnome org>]

2008/7/1 Gustavo J. A. M. Carneiro <gjc inescporto pt>:

On Mon, 2008-06-30 at 23:45 +0300, natan yellin wrote:
>
>
> On Mon, Jun 30, 2008 at 9:59 PM, Mikkel Kamstrup Erlandsen
> <mikkel kamstrup gmail com> wrote:
>         2008/6/30 Gustavo J. A. M. Carneiro <gjc inescporto pt>:
>
>         > On Mon, 2008-06-30 at 12:01 -0300, Johan Dahlin wrote:
>         >> Gustavo J. A. M. Carneiro wrote:
>         >> > On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote:
>         >> [..]
>         >>
>         >> >> Plus, CMake is getting more mature and stable and it
>         already supports
>         >> >> VisualStudio and XCode project files conversion, lack of
>         proper
>         >> >> extensibility being its only downside at the moment.
>         >> >
>         >> > Lack of extensibility, and use of another arcane custom
>         made programming
>         >> > language (if we can call it that) for everything.
>         >> >
>         >> > No, CMake is not an answer.  It is not significantly
>         better than
>         >> > autotools to justify a switch to it IMHO.
>         >>
>         >> CMake *is* considerably better. Xcode/VisualStudio are
>         killer features which
>         >> alone would make a switch worth it.
>         >
>         > I disagree that Xcode/VisualStudio are killer features.  A
>         powerful
>         > programming language and extensibility are way better
>         features IMHO.
>         > Does a significant percentage of GNOME developers use any of
>         these IDEs?
>         > Without such data you can't assert that those are killer
>         features.
>         >
>         > For the case of Vala, I don't see how CMake handles it any
>         better than
>         > autotools.
>         >
>         >>
>         >> Can we please start to organize ourselves and try to move
>         forward with
>         >> switching to another build system?
>         >
>         > We can't switch to any single build system any more than we
>         can switch
>         > to a single DVCS.  Or to a single programming language, for
>         that matter!
>         > Different developers value different features.  Modern
>         developers have
>         > to adapt to different environments.  I, for example,
>         regularly program
>         > in C, C++, and Python.  I know how to use cvs, subversion,
>         bazaar, git
>         > (poorly), and mercurial.  In particular I use subversion,
>         bazaar, and
>         > mercurial very regularly, all at the same time, git not so
>         much only
>         > because I didn't need to.  I can hack plain makefiles,
>         > autoconf/automake, waf, and scons.
>
>
>         And is this an acceptable barrier of entry to Gnome
>         development?
> Agreed. While the skills that you mentioned do come with time no
> matter what, you want to avoid forcing beginner developers to chew
> more than they can swallow.

That is a moot point.  A beginner chooses *one* project to hack on,
that's all.  All he has to know is the programming language and tools of
that single project.

GNOME is not a collection of desktop modules, is a development environment as well, and consistency within the development process and tool chain is a must for documentation, integration and to avoid effort duplication among tools.

I'd rather stick to autotools than having 3 or 4 different build systems within the GNOME module set.

In any case, most people don't choose autotools themselves, they choose whatever GNOME want to choose, and whatever people espect to use to build a GNOME module. So yes, one has to be choosen for the 90% of people who don't actually want to choose.

That is an issue when a developer wants to transition to another module,
at which point he is probably no longer a beginner.

This is basically the same thing as with programming languages.  Do you
think everything should be coded in C in order to lower the required
skill set of beginner hackers?

It's not only about beginners, but also about duplication of efforts (supporting the same tools within different build systems), ability to check how other maintainers perform a certain operation.

There should not be a big issue if a few modules choose their own build system, but select one supported choice that is used for 90% of the cases is going to help people to move forward and spend time on what really matters for us: writing the code that is being built by copy pasting what other projects have done already.

-- 
Cheers,
Alberto Ruiz