Re: building vanilla gnu.org-i18n

[Kaloian Doganov]

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.