trans-coord-devel
[Top][All Lists]
Advanced

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

Re: building vanilla gnu.org-i18n


From: Yavor Doganov
Subject: Re: building vanilla gnu.org-i18n
Date: Thu, 27 Dec 2007 19:55:49 +0200
User-agent: Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/22.1 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) (gNewSense GNU/Linux)

Явор Доганов wrote:
> 
> > Does this makes sense to you?

Sorry I didn't finish here.

The reason why I think the system would be more robust that way is
because nearly all build systems -- or at least the GNU Build System
-- work that way.  A set of rules that build what needs to be built
and global variables that override the default behaviour.  For
example, you can set CFLAGS optionally for a package or for set of
packages that will override the default value of the variable.

Likewise, you can set DEB_BUILD_OPTIONS=nostrip and rebuild a Debian
package (or a set of packages, or the whole archive) with debugging
symbols.

In our case, we can have sensible default so that `make article.xx.po'
works without hassle and do 1) optionally modify the working copy --
e.g. `cvs' without `-n'; 2) send warnings in case of `assertion
failure' -- e.g. the Scheme script exited with failure because a
webmaster broke a certain article or msgmerge failed because a
translator committed an invalid PO file; 3) send report for newly
added gettextized articles to trans-coord-news; 4) hundreds of other
things like do foo for the web fronted or do bar for the baz frontend,
statistics, wiki compiler, texinfo conversion, etc.

I agree that implementing all this additional functionality directly
in the makefile will make it more complex, but it will also make the
system more reliable, predictable and controllable, as well as
flexible to manual operation -- when and if needed.  As we rely on GNU
make (and I wouldn't imagine life otherwise), we can always separate
everything in helper functions, additional calls, etc.

I hope it is clearer now.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]