PATCH: Build test .po files during test runs

Mark Mitchell mark@codesourcery.com
Fri Mar 25 17:51:00 GMT 2005


Benjamin Kosnik wrote:
>>If you're willing to do a complete transition at this point, we can just 
>>remove LOCALEDIR from the tests, and replace that "." directly in the 
>>code.  I'd be happy with that, but that will mean that check_compile 
>>will not work, unless you have already run the tests with "make check", 
>>because it is "make check" that will actually create the message 
>>catalogs.  (That same issue would arise with the patch to check_compile 
>>that you suggested.)
> 
> 
> This usage is ok with me.
> 
> 
>>I think a complete transition would actually involve all of the 
>>following changes:
>>
>>1. The patch I posted to make DejaGNU create the .mo files, but without 
>>the setting of LOCALEDIR, as that will no longer be necessary.
>>
>>2. Modify the tests that use LOCALEDIR to just hard-code ".".
>>
>>3. Remove the rules in po/Makefile.am that create the .mo files, as this 
>>  is now done by DejaGNU.
>>
>>4. Modify testsuite_flags.in to remove the -DLOCALEDIR setting.
>>
>>5. Modify acinclude.m4 to remove glibcxx_localedir.
> 
> 
> Sounds good to me.

In the course of implementing this, I discovered that the locale files 
used by the testsuite are in fact installed, even though they contain 
dummy entries (like those for "please").  That surprised me.  The reason 
they are installed is that they also contain non-dummy entries for 
bitset error messages.

(Cleaner alternatives would be to use a separate message file for the 
testsuite, or (my favorite) to have the testsuite use non-dummy messages 
that are actually used in the runtime.  Installing message catalogs with 
dummy messages is a (minor) waste of disk space.  Anyhow, that's for 
another year.)

So, that means that I think we want Plan B, which is:

1. Modify testsuite_flags.in to remove the -DLOCAELDIR setting.

2. Set -DLOCALEDIR in DejaGNU.  This setting will have to be conditional 
on in-build-tree vs. installed-compiler testing, just as is presently 
done for setting -L paths, etc.  However, DejaGNU will not be in the 
business of building the .mo files, as we will use the ones that have 
already been built, whether in the installed or build tree.

Are you comfortable with that plan, in principle?

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304



More information about the Libstdc++ mailing list