On Tue, May 29, 2001 at 05:06:49AM -0700, Thomas Wouters wrote:
Re-BSDify the Makefiles, by not expecting make to expand '{eggs,ham}' in globs. (BSD 'make' does not, GNU make does.) I'm sure there is a more satisfying way to do this, but in this case, with only two alternatives in only two cases, just writing them out was the way of least resistance.
Ugh. I now see that there are a lot more things BSD make barfs over:
GNU make: mailman/messages$ gmake es/LC_MESSAGES/mailman.mo [ pygettext and other stuff snipped ] Generating binary catalog msgfmt -o es/LC_MESSAGES/mailman.mo es/LC_MESSAGES/mailman.po
BSD make: mailman/messages$ make es/LC_MESSAGES/mailman.mo msgfmt -o es/LC_MESSAGES/mailman.po es/LC_MESSAGES/mailman.mo es/LC_MESSAGES/mailman.mo:1: parse error es/LC_MESSAGES/mailman.mo:2: keyword "e" unknown es/LC_MESSAGES/mailman.mo:4: keyword "W" unknown
Apparently, GNU make and BSD make switch the meaning of $@ and $< in: msgfmt -o $@ $<
And there's more, there, too. As usual for Makefile/make bugs, they're hard to reproduce, depending as they are on the timestamps of seemingly totally irrelevant files :) I think it's safe to say that BSD make doesn't grok the '%/LC_MESSAGES/*' construct, though. I don't have a good GNU/BSD make resource at hand to help me through the differences; if anyone sees such a resource online, please let me know ;) In the mean time, Barry, if this isn't fixed before an almost-real release, we'll either have to ship .po files, or insist on GNU make (which is available almost everywhere, even on BSD systems, though usually as 'gmake' there.) The installation procedure works with BSD make now that I regenerated the .po files with GNU make.
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
At 02:45 PM 5/29/01 +0200, Thomas wrote:
resource at hand to help me through the differences; if anyone sees such a resource online, please let me know ;) In the mean time, Barry, if this isn't fixed before an almost-real release, we'll either have to ship .po files, or insist on GNU make (which is available almost everywhere, even on BSD systems, though usually as 'gmake' there.) The installation procedure works with BSD make now that I regenerated the .po files with GNU make.
Unless it's absolutely impossible to do otherwise, I always recommend going
with the least common denominator make. Each extra piece you require before
someone can run mailman reduces the number of people willing to bother.
And I think the "Whatinhell? It can't run with a normal make?" effect would
be the proverbial straw for a large crowd.
Ship it with pregenerated files. Include a warning that if you fiddle with the generated files, you'll probably need to install a bunch of tools, or they won't regenerate right. Included in the tools would be a make compatible with the gmake extensions. It's similar to including your autoconf and bison source files, and the generated configure and .c files, and warning people that if they want to customize, the'll need autoconf and/or bison...
I had some mail outages over the weekend so I didn't see the original message in this thread (I may still get it). Checking the archive though, it appears that there are complaints about GNU-make-isms in the message/Makefile{,.in}.
My intent is to indeed check in all the generated files, so that normally no one would ever have to run "make catalogs". My intention is that I would run those when the mailman.pot file needed updating, or when I got new translations and wanted to update the various language .po files.
So, I'm not concerned about GNU-make-isms for "make catalogs". That's why "make all" and "make install" don't depend on any of the generated files. I should probably add a comment to the top of messages/Makefile.in just saying that "make catalogs" requires GNU make.
-Barry
"BAW" == Barry A Warsaw <barry@digicool.com> writes:
BAW> So, I'm not concerned about GNU-make-isms for "make
BAW> catalogs". That's why "make all" and "make install" don't
BAW> depend on any of the generated files. I should probably add
BAW> a comment to the top of messages/Makefile.in just saying that
BAW> "make catalogs" requires GNU make.Oh, yeah. I see there was a redundant definition of the .po->.mo file transformation. I'll bet BSDmake was picking up the broken .po.mo entry and GNUmake was picking up the full rule down below.
I'll check in a fix for this shortly. -Barry
On Tue, May 29, 2001 at 02:54:35PM -0400, Barry A. Warsaw wrote:
I see there was a redundant definition of the .po->.mo file transformation. I'll bet BSDmake was picking up the broken .po.mo entry and GNUmake was picking up the full rule down below.
That's exactly what happened. I couldn't believe my eyes when I saw BSD make and GNU make attach the exact opposite meaning to $@ and $<, but I didn't think to search for redundant definitions ! I think $< is still a GNU-makeism, but I can live with requiring GNU make for building catalogs just fine.
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
TW> That's exactly what happened. I couldn't believe my eyes when
TW> I saw BSD make and GNU make attach the exact opposite meaning
TW> to $@ and $<, but I didn't think to search for redundant
TW> definitions ! I think $< is still a GNU-makeism, but I can
TW> live with requiring GNU make for building catalogs just fine.Yeah, I said to myself "no way" when I read that. It would be INSANE to swap those meanings. Then when I was cleaning up the file, I had a Homer Moment (read: "doh!" :)
-Barry
participants (3)
-
barry＠digicool.com -
Ron Jarrell -
Thomas Wouters