[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: building vanilla gnu.org-i18n
From: |
Kaloian Doganov |
Subject: |
Re: building vanilla gnu.org-i18n |
Date: |
Thu, 27 Dec 2007 21:29:51 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gNewSense gnu/linux) |
Yavor Doganov <address@hidden> writes:
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.
What is the GNU Build System? GNU Make?
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.
Those are nice features, but it's not obvious to me how they will be
implemented right now. Honestly, I didn't had them in mind. It is not
easy to say which design will fit them all. Just listing them does not
add an argument against rebuild and add/commit decoupled in two stages
(nor adds the opposite argument, of course).
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.
Using Make and the makefile is not in question. The cronjob script
could be implemented as a make target too. I wasn't discussing the
implementation language at all.
Anyway, I do not strongly oppose your suggestion. It is not dangerous
to try it. If it turns out to be a bad descision, we can still fall
back to a staged design later on.
- Re: building vanilla gnu.org-i18n, Yavor Doganov, 2007/12/08
- Re: building vanilla gnu.org-i18n, Kaloian Doganov, 2007/12/10
- Re: building vanilla gnu.org-i18n, Kaloian Doganov, 2007/12/10
- Re: building vanilla gnu.org-i18n, Yavor Doganov, 2007/12/10
- Re: building vanilla gnu.org-i18n, Kaloian Doganov, 2007/12/27
- Re: building vanilla gnu.org-i18n, Yavor Doganov, 2007/12/27
- Re: building vanilla gnu.org-i18n, Kaloian Doganov, 2007/12/27
- Re: building vanilla gnu.org-i18n, Yavor Doganov, 2007/12/27
- Re: building vanilla gnu.org-i18n, Kaloian Doganov, 2007/12/27
- Re: building vanilla gnu.org-i18n, Yavor Doganov, 2007/12/27
- Re: building vanilla gnu.org-i18n,
Kaloian Doganov <=
- Re: building vanilla gnu.org-i18n, Yavor Doganov, 2007/12/27
- Re: building vanilla gnu.org-i18n, Kaloian Doganov, 2007/12/27
- Re: building vanilla gnu.org-i18n, Yavor Doganov, 2007/12/27
- Re: building vanilla gnu.org-i18n, Kaloian Doganov, 2007/12/27
Re: building vanilla gnu.org-i18n, Kaloian Doganov, 2007/12/10