Some more information: I found the relevant string in /usr/share/locale-langpack/de/LC_MESSAGES/make.mo
which is part of Debian package language-pack-de-base, currently installed on my Ubuntu Oneiric in version 1:11.10+20111006. I have no idea if I should address you or the mentioned package maintainer (Language pack maintainers <language-pa...@ubuntu.com>). At least I could pinpoint the problem which might also exist for other strings and other languages. Alexander Kriegisch, 18.10.2011 08:28: > Thanks for answering, Paul. > > Actually, the context is as follows: I am logging the output of > > make --print-data-base --question > > in order to write my hierarchical structure of included makefiles into one, > big makefile. It is even possible to re-run make upon this big makefile with > identical results after removing some variable definitions like MAKEFLAGS, > MFLAGS, MAKECMDGOALS. This helps me to profile the impact of reading many > (and I mean many) small include files as opposed to just loading and parsing > one big makefile. The difference in our project is a significant 6.5 seconds > or so in case the hard disk read cache is empty, BTW. We will not convert > everything to one makefile, but wanted to know where we lose time. > > Anyway, the relevant part of the captured output looks like this: > > English: > >> # Pattern-specific Variable Values >> >> # No pattern-specific variable values. >> >> # Directories >> >> (...) >> # make/pciutils (device 29954, inode 750349): 5 files, 17 impossibilities. >> # make/inotify-tools/SCCS: could not be stat'd. >> # . (device 29954, inode 740347): 162 files, 68 impossibilities. >> # make/libs/libavmhmac/RCS: could not be stat'd. >> # make/Config.in (device 29954, inode 753850): could not be opened. > > German: > >> # Pattern-specific Variable Values >> >> # Keine musterspezifischen Variablenwerte. >> >> # Verzeichnisse >> >> (...) >> # make/pciutils (Gerät 29954, I-Knoten (inode) 750349): 5 Dateien, 17 >> Unmöglichkeiten. >> # make/inotify-tools/SCCS: Konnte den Status nicht feststellen. >> # . (Gerät 29954, I-Knoten (inode) 740347): 161 Dateien, 51 Unmöglichkeiten. >> # make/libs/libavmhmac/RCS: Konnte den Status nicht feststellen. >> # make/Config.in (Gerät 29954, I-Knoten (inode) 753850): >> Konnte nicht geöffnet werden. > > Please check out the last line. The German message is not just a translation > of the English one, but contains an additional line break. I just noticed > because when I was cleaning the log from comment lines, this one was a > leftover which could not be parsed when re-running make upon the big makefile > (=log). > > So the fix seems obvious: remove the additional line break from the German > message to get it in line with the original, English output. > > Regards > -- > Alexander Kriegisch > > > Paul Smith, 17.10.2011 14:22: >> On Mon, 2011-10-17 at 12:58 +0200, Alexander Kriegisch wrote: >>> I am using GNU make 3.81 on Ubuntu oneiric (11.10). I noticed that the >>> German error message "Konnte nicht geöffnet werden." is sometimes listed >>> in my output, even if I redirect stderr to /dev/null. So obviously it >>> goes to stdout. This happens for LC_ALL=de_DE@euro, but not for >>> LC_ALL=C. So maybe it is a language-specific bug or the English message >>> equals "" or something. Please check and fix this problem. >>> >>> I would be happy if you would answer to this inquiry CC to my e-mail >>> address because I am not subscribed to this list. Thanks. >> >> Hi Alexander. Google translate shows me that this message means "Could >> not be opened". >> >> I'm not sure what would show a message like that in GNU make. My >> suspicion, personally, is that this message is not coming from GNU make >> at all but rather it's being printed by a program that GNU make is >> invoking. >> >> I would need to see the context including the full text of the error >> message to know for sure. >> >> In any event, GNU make's i18n/l10n implementation never, ever changes >> anything like whether messages are printed to stdout or stderr based on >> any of the LC_* values. The only differences in behavior based on these >> settings are in the output that is printed. >> _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
