OK, I can't reproduce what you're talking about. On my Mac OS X
10.5.6 system with autoconf 2.63 from MacPorts, all of the following
52 ../configure --with-site-prefixes=/opt/local:/usr/local
53 ../configure --with-site-prefixes=/opt/MacPorts:/usr/local
55 ../configure --with-site-prefixes=/opt/MacPorts,/usr/local
57 ../configure --with-site-prefixes='/opt/MacPorts /usr/local'
61 ../configure --with-site-prefixes='/opt/MacPorts' --with-xft=emacs,tabs
where 52, 53, and 57 correctly terminate with errors because arguments
don't exist or do not "look like" prefixes, but the parse is correct;
55 errors because it (correctly, I believe) parses the comma as part
of a single path (which doesn't exist, of course); and 61 produces a
configured XEmacs build tree. My usual configuration
./configure '--with-site-prefixes=/opt/MacPorts' \
'--with-widgets=athena' '--with-athena=3d' \
'--with-zlib' '--with-modules' '--with-bignum=gmp' \
'--with-mule' '--with-xim=no' \
also works fine (generating the expected build tree). That last also
works on my Mac OS X 10.4.11 system with MacPorts, too. A couple
Mike Alexander writes:
Every --with... and --without... option is declared invalid because
Are you referring to this warning?
configure: WARNING: unrecognized options: --with-site-prefixes, --with-xft
That really is just a warning. autoconf wants to FUD us into defining
options using its AC_ARG_WITH and AC_ARG_ENABLE macros, instead of the
way we currently do it.
the definition of ac_user_opts is a colon separated list, but the
code that checks options expects a new-line separated list.
On my system, configure doesn't even contain the substring "user_o".
Any idea where that "ac_user_opts" is coming from? Where did you find
that "code that checks options"?
Have you checked to make sure that hg agrees with you that the
configure you have is the configure that was checked in by changeset
XEmacs-Beta mailing list