Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Locale-Maketext-Lexicon CPAN distribution.

Report information
The Basics
Id: 44172
Status: open
Priority: 0/
Queue: Locale-Maketext-Lexicon

People
Owner: Nobody in particular
Requestors: grousse [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.77
Fixed in: (no value)



Subject: xgettext.pl -D option behaviour doesn't match documentation
According to Locale::Maketext::Extract::Run, xgettext.pl just look recursively in directory given through -D option, adding every file not matching some exclusion pattern to the list of processed files. However, the documentation says: Add DIRECTORY to list for input files search. My understanding was than this option would just have added another directory (in addition to current one) for searching filenames enumerated on STDIN or in files given through -f option. Either the documentation or the behaviour should be changed. I'd rather change the behaviour, to match GNU gettext one, and be usable directly from Makefile.in.in installed by gettextize.
On Sun Mar 15 16:59:36 2009, GROUSSE wrote: Show quoted text
> However, the documentation says: > Add DIRECTORY to list for input files search. > My understanding was than this option would just have added another > directory (in addition to current one) for searching filenames > enumerated on STDIN or in files given through -f option.
My reading is that -D specifies a directory, and a second -D specifies ANOTHER directory. Show quoted text
> > Either the documentation or the behaviour should be changed. I'd rather > change the behaviour, to match GNU gettext one, and be usable directly > from Makefile.in.in installed by gettextize.
The current behaviour (and documentation) seems to be consistent with GNU's xgettext. If you don't specify any -D or any files, then it complains that no input files have been specified. It doesn't automatically search the current directory. I'm going to close this, as I don't see what change you would like. Feel free to reopen it if I've misunderstood it. Clint
Le Lun. Mar. 16 06:26:11 2009, DRTECH a écrit : Show quoted text
> I'm going to close this, as I don't see what change you would like. Feel > free to reopen it if I've misunderstood it.
I'd like to be able to use: xgettexp.pl foo bar -D ../ And have xgettext.pl looks for files ./foo OR ../foo, ./bar OR ../bar GNU xgettext is invoked this way in /usr/share/gettext/po/Makefile.in.in: $(XGETTEXT) --directory=$(top_srcdir) --files-from=$(srcdir)/POTFILES.in POTFILES.in contains files with path relative to top-level archive directory $(top_srcdir), not from current directory $(srcdir).
Show quoted text
> I'd like to be able to use: > xgettexp.pl foo bar -D ../ > And have xgettext.pl looks for files ./foo OR ../foo, ./bar OR ../bar >
Ah right. Gotcha. Show quoted text
> > GNU xgettext is invoked this way in /usr/share/gettext/po/Makefile.in.in: > $(XGETTEXT) --directory=$(top_srcdir) --files-from=$(srcdir)/POTFILES.in > > POTFILES.in contains files with path relative to top-level archive > directory $(top_srcdir), not from current directory $(srcdir).
Any chance you could upload a tar file with an example structure and example POTFILES that I could test against? I'm not familiar with the way this works normally. thanks Clint Show quoted text
> >
Le Lun. Mar. 16 07:53:07 2009, DRTECH a écrit : Show quoted text
> Any chance you could upload a tar file with an example structure and > example POTFILES that I could test against?
Here you have. If you try xgettext.pl -D .. --files-from=POTFILES.in in the po subdirectory, xgettext.pl will try first to access every files from the top-level directory, including unwanted files as configure.ac, when processing the -D option, and ignores files from POTFILES.in as not present in current directory.
Download sympa.tar.bz2
application/x-bzip2 16.4k

Message body not shown because it is not plain text.

Show quoted text
> If you try > xgettext.pl -D .. --files-from=POTFILES.in > > in the po subdirectory, xgettext.pl will try first to access every files > from the top-level directory, including unwanted files as configure.ac, > when processing the -D option, and ignores files from POTFILES.in as not > present in current directory.
thanks for this Guillaume. I'm not familiar with GNU's xgettext, so I have a couple of questions for you before I make changes. Forgive me for spelling this all out, but I don't want to break things. The way I've used xgettext.pl is as follows: -D $dir => add a dir to search for any extractable file (excluding /^(\.svn|blib|autogen|var|m4|local|CVS)$/ ) -f => add a particular file, relative to the current dir So you could for instance say: -D src/ -f lib/foo.pm ...which would look for any extractable files in ./src/ AND look at ./lib/foo.pm This is different from what you have described. As I understand it, you're saying that the above args would search in ./src/ for ./lib/foo.pm only, ie it would find only ./src/lib/foo.pm Is that correct? What I don't want to lose is the wild-card nature of -D - personally, I find that very useful. I'm wondering if we should add a --base-dir option, which means "look for all files relative to this dir", rather than changing the meaning of -D Another question, why do you create empty .po files in your makefile? I would have thought that you'd distribute populated .po files in your source package. Again, apologies if I'm missing something. My experience is largely Perl related. While I use make etc as an end-user, I understand very little about the build system. thanks Clint
Le Ven. Mai. 08 05:33:05 2009, DRTECH a écrit : Show quoted text
> > If you try > > xgettext.pl -D .. --files-from=POTFILES.in > > > > in the po subdirectory, xgettext.pl will try first to access every files > > from the top-level directory, including unwanted files as configure.ac, > > when processing the -D option, and ignores files from POTFILES.in as not > > present in current directory.
> > > thanks for this Guillaume. > > I'm not familiar with GNU's xgettext, so I have a couple of questions > for you before I make changes. Forgive me for spelling this all out, but > I don't want to break things. > > The way I've used xgettext.pl is as follows: > -D $dir => add a dir to search for any extractable file > (excluding /^(\.svn|blib|autogen|var|m4|local|CVS)$/ ) > -f => add a particular file, relative to the current dir > > So you could for instance say: > -D src/ -f lib/foo.pm > > ...which would look for any extractable files in ./src/ AND look at > ./lib/foo.pm > > This is different from what you have described. As I understand it, > you're saying that the above args would search in ./src/ for > ./lib/foo.pm only, ie it would find only ./src/lib/foo.pm > > Is that correct?
Yes. Show quoted text
> What I don't want to lose is the wild-card nature of -D - personally, I > find that very useful. > > I'm wondering if we should add a --base-dir option, which means "look > for all files relative to this dir", rather than changing the meaning
of -D I'd personally prefer to change -D option behaviour, to match GNU gettext interface, and eventually have another option for current behaviour. But it would xgettext.pl user habits, tough, so I understand your point. Show quoted text
> Another question, why do you create empty .po files in your makefile?
There wasn't any makefile in the submitted archive, where do you see empty po files creation ?
Subject: Re: [rt.cpan.org #44172] xgettext.pl -D option behaviour doesn't match documentation
Date: Fri, 08 May 2009 14:58:25 +0200
To: bug-Locale-Maketext-Lexicon [...] rt.cpan.org
From: Clinton Gormley <clint [...] traveljury.com>
Show quoted text
>
> > Another question, why do you create empty .po files in your makefile?
> There wasn't any makefile in the submitted archive, where do you see > empty po files creation ?
In your previous emails, you say that you're calling xgettext.pl from your makefile. What you sent me contains the POTFILE but no .po files. I would have thought that you would run the xgettet.pl while developing, then included the resulting .po files in what you distribute. But quite possibly, I'm missing the point somewhere :) clint
Le Ven. Mai. 08 08:58:49 2009, clint@traveljury.com a écrit : Show quoted text
>
> >
> > > Another question, why do you create empty .po files in your makefile?
> > There wasn't any makefile in the submitted archive, where do you see > > empty po files creation ?
> > In your previous emails, you say that you're calling xgettext.pl from > your makefile. What you sent me contains the POTFILE but no .po files.
Ah, yes, it was a minimalist testcase :) The actual code is here: http://sourcesup.cru.fr/cgi/viewvc.cgi/branches/sympa-autotools-cleanup/po