Re: Using vala in GNOME

["Alberto Ruiz" <aruiz gnome org>]

2008/6/30 Gustavo J. A. M. Carneiro <gjc inescporto pt>:

On Mon, 2008-06-30 at 15:07 +0100, Alberto Ruiz wrote:
>
>
> 2008/6/30 Gustavo J. A. M. Carneiro <gjc inescporto pt>:
>
>
>         An excellent reason to switch to a more modular build system,
>         one that
>         does not require patching the core in order to extend it.
>
>         Something like... WAF :-)
>
> Well, after some time evaluating waf, there's something that I don't
> quite like about it and that I don't see changing anytime soon.
>
> During its development cycle last year trunk has been broken a few
> times, api has changed and the Tools modules to support gnome features
> have stopped working. Last time I checked, it lacks a proper test
> suite to avoid regression on supported tools.
>
> There's no difference between well supported features and unstable
> ones, so people using those extensions don't know what sort of
> stability they should spect.
>
> As we talk, the gnome demo at trunk is broken, a situation that I've
> seen more times than I would like too:
>   File "/home/aruiz/src/waf-read-only/demos/gnome/wscript", line 6, in
> <module>
>     import Params, intltool, gnome
> ImportError: No module named Params
>
> Yes, I think that waf has a lot of potential, and eventually it would
> be the way to go, but without a significant change of direction in the
> way it is maintained, I don't see GNOME changing to it anytime soon.

Yes, I wholehartedly agree.  I periodically discuss these things with
the maintainer, to try to change his habits, but it's no use :(

Ideally we would need a fork of WAF, with a maintainer that understands
how software cycles should work.  However, the current maintainer is a
good developer (if not a good maintainer) and would be a shame to lose
his contributions, on one hand, and no one else has time to maintain a
fork of WAF, on the other hand.

My gut feeling is that he's not aware that such things have such a big impact, and maybe we have a hard time to explain him what the concrete problems actually are, maybe if we list down concrete examples of which practices would be needed to adopt within the waf development model he will change his mind.

Please, use the wiki page to list every concerns and advantages that you found with waf and CMake
 

The solution I come up with now is to just freeze the WAF version I use.
Fortunately, things like vala support can be done on top, rather than
within, WAF, so it's not hard to stabilize on a WAF version for a very
long time.

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

--

Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
"The universe is always one step beyond logic" -- Frank Herbert

-- 
Un saludo,
Alberto Ruiz