Re: Using vala in GNOME

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.

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]