Jerry James writes: Didn't we have this discussion when I originally submitted the patch to Makefile.common? Anyway: cd ./modules/postgresql && make CC='gcc' CFLAGS='-Wall -Wno-switch -Winline -Wmissing-prototypes -Wsign-compare -Wundef -Wstrict-prototypes -Wshadow -Wmissing-declarations -Wpointer-arith -g -O3' LDFLAGS='' CPPFLAGS='' all ../../lib-src/ellcc -Wall -Wno-switch -Winline -Wmissing-prototypes -Wsign-compare -Wundef -Wstrict-prototypes -Wshadow -Wmissing-declarations -Wpointer-arith -g -O3 --mode=compile --mod-output=postgresql.o -I../../src -I/home/rpluim/xemacs/xemacs-21.5/modules/postgresql/../../src -c /home/rpluim/xemacs/xemacs-21.5/modules/postgresql/postgresql.c ELLMAKEDOC=../../lib-src/make-docfile ../../lib-src/ellcc --mode=init --mod-output=postgresql_i.c --mod-name=postgresql --mod-version=1.0.0 --mod-title="PostgreSQL Client Interface for XEmacs" $(srcdir)/postgresql.c srcdir: not found /postgresql.c: No such file or directory I have no idea if this breaks on other BSDs. (There are days when I feel like Martin, really I do) If you did this, it would be best if it was: #if MAKE_DOESNT_NEED_COLON_FOR_EXPANSION since that doesn't tie it to any particular sets of operating systems (especially since I could probably make a case that FreeBSD's behaviour is a bug, and thus it might get fixed). However, I'd prefer mandating GNU make to all sorts of configure-fu just for this. (and that would also have the advantage that we could just stop worrying about different makes. Is there a single platform we support that does _not_ possess a gnu make port?). Robert Robert

Robert> Is there a single platform we support that does _not_ Robert> possess a gnu make port? For practical purposes, VC++ doesn't. But we have a whole separate Makefile for that, so I guess that's the exception that proves the rule. Then again there's fscking ProjectBuilder/jam on Mac OS X.... -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Adrian Aichner <adrian(a)xemacs.org&gt; wrote: End users don't compile the packages; they just download them. End users don't build the web pages; they just view them. End users DO build XEmacs from sources. Requiring GNU make for XEmacs itself is a much more significant step than requiring it for the packages and xemacsweb. I do. I think we will decrease our pool of users if we drop support for non-GNU makes. It isn't that there are people who cannot build and install GNU make; it's the nuisance factor. Some sysadmins may just refuse to play along. And it isn't as though we are in terrible shape, either. We currently have a set of Makefiles that seem to work pretty well on the makes people are currently using. Throwing that all away because of a few nuisances seems a bit extreme. The current problem appears to be that there exists a make that fails to expand variables occurring inside of a pattern matching expression on the right hand side of an =. Since the same make successfully expands those variables when := is used instead, we can easily write a configure test to detect and work around this. I'll do just that in a few minutes. If we were starting from scratch, I would worry about the make variants. But we already have a bunch of infrastructure for dealing with them. I think it is worth a little effort now and then to keep up with those variants. Dump the work on me if nobody else wants to do it. I'll collect all the make variants I can find and successfully build on some platform I have and try them out from time to time. -- Jerry James http://www.ittc.ku.edu/~james/

Jerry James writes: Works fine here with both native and gnu make. Looks good. Nope. It's still needed for the include flags. Robert

That all sounds good to me, Jerry -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/