Stephen> Instead, work on configure.ac. Yes please do. I've yet to receive any comments on the patch, or the output of the regression test from any systems apart from my own. I'd some to have some of both before progressing any further. Malcolm -- Malcolm Purvis <malcolmp(a)xemacs.org&gt;

I have finally had a change to look at Ben's bug report concerning autoconf.ac. Ben> This chunk at the end looks wrong: Ben> ＠＠ -5660,10 +5675,8 ＠＠ Ben> dnl Create a GNUmakefile and Makefile from Makefile.in. Ben> changequote(<<,>>)dnl Ben> -dnl CPP_MAKEFILE(CPPFLAGS,filename) Ben> -define(<<CPP_MAKEFILE>>, Ben> -echo creating $dir/<<$2>> Ben> -$CPP -I. -I${top_srcdir}/src <<$1>> junk.c \ Ben> +echo creating $dir/Makefile Ben> +$CPP -I. -I${top_srcdir}/src -DUSE_GNU_MAKE junk.c \ Ben> dnl Delete line directives inserted by $CPP Ben> | sed -e 's/^\#.*//' \ Ben> dnl Delete spurious blanks inserted by $CPP Ben> ＠＠ -5678,15 +5691,8 ＠＠ Ben> s/\"[ TAB]*$// Ben> }' > Makefile.new Ben> chmod 444 Makefile.new Ben> - mv -f Makefile.new <<$2>> Ben> -)dnl CPP_MAKEFILE Ben> - Ben> - CPP_MAKEFILE(,Makefile) Ben> - CPP_MAKEFILE(-DUSE_GNU_MAKE,GNUmakefile) Ben> - if test -r "xemacs.def.in"; then Ben> - cp -f xemacs.def.in junk.c Ben> - CPP_MAKEFILE(,xemacs.def) Ben> - fi Ben> + mv -f Makefile.new Makefile; cp Makefile GNUmakefile Ben> +dnl Ben> changequote([,])dnl Ben> rm -f junk.c Ben> ) Ben> It deletes the stuff that creates GNUmakefile separately, and just copies Ben> one to the other. I'm mystified by this chunk because it is not in my original patch nor in CVS. I did have it in my workspace for a while because I thought I could eliminate GNUmakefile but I can remember publishing it. In summary, the existing configure.in behaviour is in configure.ac. Malcolm - Going Mad. -- Malcolm Purvis <malcolmp(a)xemacs.org&gt;

Ben> This, and everything else I've been posting recently, is from Ben> old workspaces. I've already done a bunch of work on Ben> configure.in; I just haven't merged it. One such Ben> particularly major change redoes things so that you can Ben> compile a single XEmacs with both X11 and GTK support. It's not an "old" workspace to me; this is the first I've heard of it (and I've asked you on at least two occasions to describe what you have in process). I'm sorry, but if you post patches to configure.in in 21.5, I'm afraid it's a waste of your time and ours; configure development has moved on to ac2.5x. The SuSE guys' patch is maybe 6 months old, and Malcolm has also published a more comprehensive patch. They got there first, and I hope that in a short time we will be using the ac2.5x-based configure. Not to mention that I've already ported my Xft support to ac2.59, and will commit to my Xft branch shortly. Moving on here is pretty important, actually---ac2.5x is sine qua non for the SuSE guys, and there is a move afoot to get a 21.5-based package into the next major release of SuSE, which looks like freezing in the near future. That would be very helpful in terms of mind share in a market which actually contributes back to the project in terms of code and other support. -- 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.

Ben> Until someone checks in configure.ac, it's *their* responsibility, imo, Ben> to keep up with patches to configure.in. I agree :-) My configure.ac workspace currently has all the recent changes to configure.in except for Ben's last patch to separate out optimization and debugging cflags (and this is missing only due at a lack of time on my part). I plan to keep tracking the changes until we cut over. Because this is such an major change, I wasn't planning to it check it in until I had recieved a few more comments (of the 'it does/doesn't work on my system' variety). Until then I have no problem with people making changes to configure.in. BTW, Stephen's comments about SuSe mean that I should look into doing a 21.4 version as well so that we can make their release schedule? I know that SteveY would be happy if I did :-) Malcolm -- Malcolm Purvis <malcolmp(a)xemacs.org&gt;

Ben> Until someone checks in configure.ac, it's *their* Ben> responsibility, imo, to keep up with patches to configure.in. Malcolm> I agree :-) Well, that's up to you. But I disagree when it comes to new features. I would really prefer you help Ben port his features forward to configure.ac now, and abandon the work on configure.in---leave that as a fallback in case either you or Ben hosed configure.ac. And it's not just your effort/needs: I've already put in several hours on configure.ac (and regressiontest.pl), and Steve Youngs would like a robust version asap, too. Malcolm> Until then I have no problem with people making changes Malcolm> to configure.in. I do, though, because I will be checking in your changes plus my own to the sjt-xft branch as soon as I find time to do it---I have some experimental autocrap of my own to support Xft development that I would be unwilling to commit to the mainline. Malcolm> BTW, Stephen's comments about SuSe mean that I should Malcolm> look into doing a 21.4 version as well so that we can Malcolm> make their release schedule? No. SuSE has their patch for 21.4. The issue for them is purely political, to make it look like we're doing the kinds of things we need to do to make 21.5 a product they can support. You're certainly welcome to do an SXEmacs version, but I see no gain and lots of pain from applying to 21.4. But if I were Steve Y, I'd just stick that thing in there and see what breaks. I bet on "not much, and that very obvious to diagnose and fix". -- 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.