unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Julien Lepiller <julien@lepiller.eu>
To: Miguel <rosen644835@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH 1/2] bootstrap: Break automake dependency on generated files. (was Re: Let’s translate!)
Date: Wed, 24 Apr 2019 12:37:19 +0200	[thread overview]
Message-ID: <20190424123719.502ff14f@sybil.lepiller.eu> (raw)
In-Reply-To: <20190424005137.6e07a8b6@gmail.com>

Le Wed, 24 Apr 2019 00:51:37 +0200,
Miguel <rosen644835@gmail.com> a écrit :

> Hi,
> 
> El Tue, 23 Apr 2019 16:30:26 +0200
> Ludovic Courtès <ludo@gnu.org> escribió:
> > Hello,
> > 
> > Julien Lepiller <julien@lepiller.eu> skribis:
> >   
> > > This is a very good idea, but I think it leaves a stub texi that
> > > won't get rebuilt because it's younger than po files. What if we
> > > add a toucgh invocation to reset the modification time of these
> > > stubs, to ensure make will want to rebuild them?    
> > 
> > Also, I don’t actually use the ./bootstrap script.  :-)  
> 
> Currently it is only a call to autoreconf -fvi, but it's there for a
> reason, isn't it?
> 
> > Shouldn’t we instead replace the existing %.texi targets in
> > doc/local.mk with a phony target like ‘update-texi’, and then add:
> > 
> >   dist-hook: update-texi
> > 
> > ?  
> 
> The procedure needed currently to a new translation for the manual is:
>   1. modify doc/local.mk, po/doc/local.mk and so on. 
>   2. guix.LL.texi must be manually generated somehow even though it is
>   listed in BUILT_SOURCES.
>   3. automake can run without errors with the rules in order to
> generate the actual translated file.
>   4. The resulting files are committed.
> 
> The problem is that automake parses .texi files for the @setfilename
> tag. On the other hand, guix.LL.texi and contributing.LL.texi are
> generated files, and they shouldn't be on the VCS, just like neither
> configure nor Makefile.in are, though they are distributed. My patch
> tries to avoid this issue creating stub files that will be overwritten
> with the actual content. This has the advantage of keeping clean git
> status from other modifications than .po files changes.
> 
> This may sound familiar to this community, it actually is a bootstrap
> problem. Running autoreconf -fvi actually tells you that that file is
> missing, so that part is easy to fix. On the other hand, as far as I
> tested if it does not contain a line with version-LL.texi,
> version-LL.texi won't be generated.
> 
> Happy hacking,
> Miguel

I actually agree with Miguel here. The phony target would not allow us
to update the manual. It's probably a matter of preferences, but I
prefer an up to date manual with some English sentences than a fully
translated but outdated manual. I wouldn't use a manual that could
refer to an older version.

Also Miguel's solution looks a lot more clean in the bootstrapping
point of view, and I think this is a strong argument in this
community :)

You will only be bothered when new translations appear, in which case
you'll have to run ./bootstrap again, but on the other hand, you will
never be bothered by *.texi files being changed all the time.

  reply	other threads:[~2019-04-24 10:37 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11  9:54 New template for 'guix-manual' made available Translation Project Robot
2019-04-12 20:43 ` Let’s translate! Ludovic Courtès
2019-04-13  1:56   ` Meiyo Peng
2019-04-13  6:45     ` pelzflorian (Florian Pelz)
2019-04-13  7:49       ` pelzflorian (Florian Pelz)
2019-04-13  9:33       ` Meiyo Peng
2019-04-13  7:14     ` Julien Lepiller
2019-04-13  9:27       ` Meiyo Peng
2019-04-23  0:42       ` [PATCH 0/2] Removal of generated files (was Re: Let’s translate!) Miguel
2019-04-23  0:43         ` [PATCH 1/2] bootstrap: Break automake dependency on generated files. " Miguel
2019-04-23  7:28           ` Julien Lepiller
2019-04-23 10:28             ` Miguel
2019-04-26  9:30               ` Julien Lepiller
2019-04-26 11:05                 ` Miguel
2019-04-26 18:55                   ` Julien Lepiller
2019-04-26 22:10                     ` Ludovic Courtès
2019-04-27 12:32                       ` Julien Lepiller
2019-04-27 13:52                         ` Ludovic Courtès
2019-04-23 14:30             ` Ludovic Courtès
2019-04-23 22:51               ` Miguel
2019-04-24 10:37                 ` Julien Lepiller [this message]
2019-04-25  8:50                   ` Ludovic Courtès
2019-04-25  9:54                     ` Julien Lepiller
2019-04-26  8:39                       ` Ludovic Courtès
     [not found]         ` <20190423024427.10cd6e87@gmail.com>
2019-04-23 22:42           ` [PATCH 2/2] doc: Add Spanish translation. " Ludovic Courtès
2019-04-13  7:49     ` Let’s translate! znavko
2019-04-13  9:46       ` Meiyo Peng
2019-04-15 12:38     ` Ludovic Courtès
2019-04-13  5:11 ` znavko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190424123719.502ff14f@sybil.lepiller.eu \
    --to=julien@lepiller.eu \
    --cc=guix-devel@gnu.org \
    --cc=rosen644835@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).