Karl Berry <[email protected]> writes: > where glob patterns are allowed to avoid repetition. > > Allowed but required? Not sure if this would come for free. E.g., a > particular foo.cpp file might have a special keyword that bar.cpp (or > *.cpp in general) does not. This actually happens in Texinfo, although > thankfully in our cases it does not hurt to define our special keyword > for all files.
In such cases, I guess we could let people write other file names explicitly without using glob, or adopt the !-patterns from git. > *.cpp --keyword ... > > I wonder about adding a keyword to the beginning of the line, like > file *.cpp --keyword ... > > That way, if later on it turns out to be useful to define other aspects > of gettext configuration in the same file, another keyword could be used > and it would all be nicely parallel. I am not sure if there will be any configuration aspects other than files. Do you have anything particular in mind? If only per-file options are sufficient, I would propose to name the file as POTFILES.opts, so it looks clear that the file complements POTFILES.in. > Which makes me think of another possibility, though I'm not sure if it > makes sense: maybe such additional config could be optionally added to > Makevars, which users are already (supposed to) edit. Instead of > creating a separate/second file. That might make sense; I suppose you mean to pass the per-file options through XGETTEXT_OPTIONS? > and a user needs to check if the option is available. > > Maybe the user could declare at some level (AM_GNU_GETTEXT, Makevars, ?) > that such an options file is used and then the pot-update code can check > that (a) the file exists, and (b) the version of xgettext is sufficient. Yes, we could do that exactly, in a similar way that the pot-update code checks xgettext/msgmerge versions. I tend to think if we could generalize the version checks and move them to m4/po.m4 so all the version checks can be done at configure time, though I am not sure if it is feasible. Regards, -- Daiki Ueno
