6:59 p.m.
There is absolutely no logic to whether an option is with-FOO or
enable-FOO. This should be fixed.
Why don't we just dump this distinction entirely and have everything be
with-FOO?
8:39 p.m.
Ben Wing <ben(a)666.com> writes:
There is absolutely no logic to whether an option is with-FOO or
enable-FOO. This should be fixed.
The logic is supposed to be the following:
--with-foo:
Require (or disable with --require) the use of external software
that XEmacs can link with and/or interface to. Hypothetical
examples: --with-berkeley-db, --with-gnome, --with-ssl, --with-tiff
These are typically turned off to reduce the number of dependencies of
the resulting XEmacs, or sometimes to suppress autodetection of those
libraries when such autodetection is buggy.
--enable-foo:
Gives user the choice whether to include "optional compile-time
features" into his XEmacs. Hypothetical examples: --enable-md5,
--enable-optimization, --enable-bignum, --enable-error-checking,
--enable-mule
These feaures are typically turned off to reduce code size or to
remove unnecessary (error-checking), experimental (bignum) or
untrusted (mule) features from the executable.
If a feature includes both interfacing to external software and
considerable amounts of internal code, `--with' is a safe choice.
When the software is internal or must be present in the source tree,
`--enable' should be used; it should have been `--enable-infodock'.
Some options don't follow in any of those two categories, and I'm not
sure how those are "supposed" to be handled.
Why don't we just dump this distinction entirely and have
everything
be with-FOO?
The idea is that people familiar with the Autoconf conventions find
XEmacs's configure easy to use. While those conventions do not bind
us, it's a good thing to respect them when possible.
9:09 p.m.
Hrvoje Niksic <hniksic(a)xemacs.org> writes:
Ben Wing <ben(a)666.com> writes:
> There is absolutely no logic to whether an option is with-FOO or
> enable-FOO. This should be fixed.
The logic is supposed to be the following:
--with-foo:
Require (or disable with --require) the use of external software
Hi Hrvoje, I don't understand^^^^^^^^^
Shouldn't that be
`--without-FEATURE' or `--with-FEATURE=no'
Adrian
--
Adrian Aichner
mailto:adrianï¼ xemacs.org
http://www.xemacs.org/
9:13 p.m.
Adrian Aichner <adrian(a)xemacs.org> writes:
> --with-foo:
> Require (or disable with --require) the use of external software
Hi Hrvoje, I don't understand^^^^^^^^^
It's a typo resulting from pasting the Autoconf manual, sorry.
Shouldn't that be
`--without-FEATURE' or `--with-FEATURE=no'
You're right.
3:10 a.m.
Hrvoje Niksic wrote:
Ben Wing <ben(a)666.com> writes:
>There is absolutely no logic to whether an option is with-FOO or
>enable-FOO. This should be fixed.
>
>
The logic is supposed to be the following:
--with-foo:
Require (or disable with --require) the use of external software
that XEmacs can link with and/or interface to. Hypothetical
examples: --with-berkeley-db, --with-gnome, --with-ssl, --with-tiff
These are typically turned off to reduce the number of dependencies of
the resulting XEmacs, or sometimes to suppress autodetection of those
libraries when such autodetection is buggy.
we have --enable-database={berkdb,...}, --enable-sound={nas,esd,...}
--enable-foo:
Gives user the choice whether to include "optional compile-time
features" into his XEmacs. Hypothetical examples: --enable-md5,
--enable-optimization, --enable-bignum, --enable-error-checking,
--enable-mule
bignum and tiff both require external libraries; so why is one --enable
and one --with in your examples?
These feaures are typically turned off to reduce code size or to
remove unnecessary (error-checking), experimental (bignum) or
untrusted (mule) features from the executable.
If a feature includes both interfacing to external software and
considerable amounts of internal code, `--with' is a safe choice.
When the software is internal or must be present in the source tree,
`--enable' should be used; it should have been `--enable-infodock'.
Some options don't follow in any of those two categories, and I'm not
sure how those are "supposed" to be handled.
This is the majority of our configure features, and they're randomly
distributed between --enable and --with.
How about --with-toolbars but --enable-menubars?
>Why don't we just dump this distinction entirely and have everything
>be with-FOO?
>
>
The idea is that people familiar with the Autoconf conventions find
XEmacs's configure easy to use. While those conventions do not bind
us, it's a good thing to respect them when possible.
The problem is, for the vast majority of features, my guess is wrong 50%
of the time.
9:25 a.m.
>>>> "Ben" == Ben Wing <ben(a)xemacs.org>
writes:
Ben> The problem is, for the vast majority of features, my guess
Ben> is wrong 50% of the time.
You're right, they're inconsistent, and we should fix them. I fixed a
few when Malcolm submitted the patch but obviously I didn't catch all
of them. Let's try to do it all at once, though---no COMMIT until we
have a bunch of APPROVEs.
I think the right thing to do is to get rid of the distinction and
just use "--with-FEATURE", because there are too many features where
the distinction simply doesn't make sense.
The problem is that the Autoconf people have definitely made changes
that amount to enforcing their preferred style in some but not all
cases. I'd like to avoid that if possible, but I'm not sure what the
best way is.
--
School of Systems and Information Engineering 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.
11:06 a.m.
Stephen J. Turnbull wrote:
>>>>>"Ben" == Ben Wing <ben(a)xemacs.org>
writes:
>>>>>
>>>>>
Ben> The problem is, for the vast majority of features, my guess
Ben> is wrong 50% of the time.
You're right, they're inconsistent, and we should fix them. I fixed a
few when Malcolm submitted the patch but obviously I didn't catch all
of them. Let's try to do it all at once, though---no COMMIT until we
have a bunch of APPROVEs.
I think the right thing to do is to get rid of the distinction and
just use "--with-FEATURE", because there are too many features where
the distinction simply doesn't make sense.
Me too.
The problem is that the Autoconf people have definitely made changes
that amount to enforcing their preferred style in some but not all
cases. I'd like to avoid that if possible, but I'm not sure what the
best way is.
Don't worry about them.
12:35 p.m.
On Tue, Sep 27, 2005 at 05:25:04PM +0900, Stephen J. Turnbull wrote:
You're right, they're inconsistent, and we should fix them.
I fixed a
few when Malcolm submitted the patch but obviously I didn't catch all
of them. Let's try to do it all at once, though---no COMMIT until we
have a bunch of APPROVEs.
Can't we just make enable and with synonyms?
OG.
9:59 a.m.
Ben Wing <ben(a)xemacs.org> writes:
>The logic is supposed to be the following:
>
>--with-foo:
> Require (or disable with --require) the use of external software
> that XEmacs can link with and/or interface to. Hypothetical
> examples: --with-berkeley-db, --with-gnome, --with-ssl, --with-tiff
>
>These are typically turned off to reduce the number of dependencies of
>the resulting XEmacs, or sometimes to suppress autodetection of those
>libraries when such autodetection is buggy.
>
>
>
we have --enable-database={berkdb,...}, --enable-sound={nas,esd,...}
They should have been "--with" according to Autoconf logic. That's
why I said what logic is "supposed to be" rather than "is".
>--enable-foo:
> Gives user the choice whether to include "optional compile-time
> features" into his XEmacs. Hypothetical examples: --enable-md5,
> --enable-optimization, --enable-bignum, --enable-error-checking,
> --enable-mule
>
>
bignum and tiff both require external libraries; so why is one
--enable and one --with in your examples?
Sorry, I keep forgetting that bignum requires an external library.
How about --with-toolbars but --enable-menubars?
Both sound like --enable material to me since they require external
libraries.
2:10 p.m.
>>>> "Ben" == Ben Wing <ben(a)xemacs.org>
writes:
Ben> we have --enable-database={berkdb,...}, --enable-sound={nas,esd,...}
I wouldn't get to hung up on the idea that referencing an external library
must mean that --with has be used instead of --enable.
When I assigned the new flags I interpreted the definitions that Hrvoje posted
as followed:
- If the feature changed what I thought what the nature of XEmacs was then is
was given --enable, even if it also referred to external libraries.
- If the feature was more of an implementation detail of XEmacs' nature then
it was with --with.
eg,
- XEmacs with MULE or bignums is a different beast to one without either,
so both get --enable.
- XEmacs with widgets is different to XEmacs without and gets --enable, but
the choice of toolkit that implements that widgets doesn't changes XEmacs'
nature so it given --with.
That's not so say that my choices are perfect.
Ben> How about --with-toolbars but --enable-menubars?
It's actually --enable-toolbars. The --with-toolbars is a typo in the help
string.
To answer Olivier's question, aliasing --with and --enable wouldn't be too
difficult with a bit of macro magic but doing so would would tie us into
knowing the implementation of yet another autoconf macro. We currently only
override one autoconf macro (AC_LANG(C)) and I'd like to avoid doing more if
ai all possible because it this sort of detailed knowledge that made moving up
from autoconf 2.13 so hard in the first place.
However, it the new options are genuinely causing confusion, and it is not
just a case of muscle memory typing in the old options, I'll happily produce
an aliasing patch.
Malcolm
--
Malcolm Purvis <malcolmp(a)xemacs.org>
4:06 p.m.
>>>> "Malcolm" == Malcolm Purvis
<malcolmp(a)xemacs.org> writes:
Malcolm> I wouldn't get to hung up on the idea that referencing an
Malcolm> external library must mean that --with has be used
Malcolm> instead of --enable.
What you are missing is that the semantics of --with-foo and
--enable-bar are defined not by us, but by the Autoconf developers.
At present, I don't think there is a substantial difference so we can
make arbitrary choices, but I could see them doing something like
assuming that --enable-bar takes a boolean or similar, which would
hose any --enables that take library or multiple arguments.
Malcolm> To answer Olivier's question, aliasing --with and
Malcolm> --enable wouldn't be too difficult with a bit of macro
Malcolm> magic
I'll veto that unless it buys more than a little clarity in specifying
arguments. We could just as easily simply not use the --enable forms
at all.
The other thing we could do is complete the set of "wrong way options"
that are checked (eg, --with-mule will tell you to use --enable-mule),
and extend them to check multiple options in one invocation.
--
School of Systems and Information Engineering 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.
11:12 p.m.
On Wed, Sep 28, 2005 at 12:06:24AM +0900, Stephen J. Turnbull wrote:
The other thing we could do is complete the set of "wrong way
options"
that are checked (eg, --with-mule will tell you to use --enable-mule),
and extend them to check multiple options in one invocation.
"To get Mule you have to dance on one foot."
"Nice, but no, the other foot."
OG.
5:31 a.m.
Malcolm Purvis wrote:
>>>>>"Ben" == Ben Wing <ben(a)xemacs.org>
writes:
>>>>>
>>>>>
Ben> we have --enable-database={berkdb,...}, --enable-sound={nas,esd,...}
I wouldn't get to hung up on the idea that referencing an external library
must mean that --with has be used instead of --enable.
When I assigned the new flags I interpreted the definitions that Hrvoje posted
as followed:
- If the feature changed what I thought what the nature of XEmacs was then is
was given --enable, even if it also referred to external libraries.
- If the feature was more of an implementation detail of XEmacs' nature then
it was with --with.
eg,
- XEmacs with MULE or bignums is a different beast to one without either,
so both get --enable.
- XEmacs with widgets is different to XEmacs without and gets --enable, but
the choice of toolkit that implements that widgets doesn't changes XEmacs'
nature so it given --with.
That's not so say that my choices are perfect.
But:
[1] this distinction has little relevance to the "feature" vs
"package"
distinction.
[2] i can't follow the logic of many of the choices. why --enable-sound
but --with-png? what's the difference between sound and graphics? and
--with-x but --enable-database? Is database support really more
"fundamental" than X support? and --enable-quick-build certainly doesn't
belong. it really seems that there's no non-arbitrary way to divide up
the options.
6:52 a.m.
>>>> "Ben" == Ben Wing <ben(a)xemacs.org>
writes:
Ben> Malcolm Purvis wrote:
> - If the feature changed what I thought what the nature of
> XEmacs was then is was given --enable, even if it also referred
> to external libraries.
> - If the feature was more of an implementation detail of
> XEmacs' nature then it was with --with.
I think that's reasonable in theory, but pragmatically it has two
problems. First, many people take the Autoconf scheme seriously.
Second, even without that bias, people will have varying intuitions
about "nature of XEmacs" vs. "implementation detail."
Ben> [1] this distinction has little relevance to the "feature" vs
Ben> "package" distinction.
N.B. Malcolm explicitly disclaims following that rule.
Ben> [2] i can't follow the logic of many of the choices. why
Ben> --enable-sound but --with-png? what's the difference between
Ben> sound and graphics? and --with-x but --enable-database? Is
Ben> database support really more "fundamental" than X support?
I'm not sure offhand, but ISTR these particular examples have to do
with my hack to support multiple independent ways of providing a class
of feature. So there's a local Autoconf macro that allows you to
define a feature "foo" that can be supported with "bar" or
"baz". It
automatically supports "all", "none", and "no-OPTION" to
turn off
OPTION as a comma-separated list.
IIRC, I did this only for --enable-foo which was bogus.
Ben> and --enable-quick-build certainly doesn't belong.
Well, --enable is the obvious correct choice for quick-build according
to the Autoconf scheme, since it doesn't require any software not
provided in the XEmacs sources.
Ben> it really seems that there's no non-arbitrary way to divide
Ben> up the options.
I think everybody agrees with that. The question is more (1) whether
we can be consistent enough without a macro aliasing --with to
--enable, and (2) if not, if that's worth doing, and (3) if the
answers are "no" and "no", what else can we do?
FWIW, my answer to (1) is "yes", and (2) is "no". I don't really
have
a good answer to (3).
The rule I propose for (1) is "If it requires installing other
software to be linked with XEmacs on one or more officially supported
platforms, it's '--with', otherwise, it's '--enable'."
Modules can
always be directly linked to XEmacs, so evaluate the rule at
--disable-modules.
So it's --enable-quick-build and --with-png. True, many platforms
come with X11 installed, but Mac OS X and Windows don't (and most
Linux distros require installing the dev packages), so it's
--with-x11.
The main one that I find confusing is widgets. Should it be
--enable-widgets --with-athena=3d, or should it be
--with-widgets=athena --with-athena=3d?
I tend to prefer the former, on the grounds that mixing and matching
widget sets is ugly and bug-prone, but in theory you can mix Athena
with Motif, and we do have the Lucid "native" widgets like the
menubar. So as a practical matter we may need to allow different
widget sets for menubar, dialogs, scrollbars, and widgets, implying
--with-menubar, --with-dialogs, --with-scrollbars, and --with-widgets.
--
School of Systems and Information Engineering 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.
7:52 a.m.
Stephen J. Turnbull wrote:
>>>>>"Ben" == Ben Wing <ben(a)xemacs.org>
writes:
>>>>>
>>>>>
Ben> Malcolm Purvis wrote:
>> - If the feature changed what I thought what the nature of
>> XEmacs was then is was given --enable, even if it also referred
>> to external libraries.
>> - If the feature was more of an implementation detail of
>> XEmacs' nature then it was with --with.
I think that's reasonable in theory, but pragmatically it has two
problems. First, many people take the Autoconf scheme seriously.
Second, even without that bias, people will have varying intuitions
about "nature of XEmacs" vs. "implementation detail."
Ben> [1] this distinction has little relevance to the "feature" vs
Ben> "package" distinction.
N.B. Malcolm explicitly disclaims following that rule.
Ben> [2] i can't follow the logic of many of the choices. why
Ben> --enable-sound but --with-png? what's the difference between
Ben> sound and graphics? and --with-x but --enable-database? Is
Ben> database support really more "fundamental" than X support?
I'm not sure offhand, but ISTR these particular examples have to do
with my hack to support multiple independent ways of providing a class
of feature. So there's a local Autoconf macro that allows you to
define a feature "foo" that can be supported with "bar" or
"baz". It
automatically supports "all", "none", and "no-OPTION" to
turn off
OPTION as a comma-separated list.
IIRC, I did this only for --enable-foo which was bogus.
Ben> and --enable-quick-build certainly doesn't belong.
Well, --enable is the obvious correct choice for quick-build according
to the Autoconf scheme, since it doesn't require any software not
provided in the XEmacs sources.
Ben> it really seems that there's no non-arbitrary way to divide
Ben> up the options.
I think everybody agrees with that. The question is more (1) whether
we can be consistent enough without a macro aliasing --with to
--enable, and (2) if not, if that's worth doing, and (3) if the
answers are "no" and "no", what else can we do?
FWIW, my answer to (1) is "yes", and (2) is "no". I don't really
have
a good answer to (3).
The rule I propose for (1) is "If it requires installing other
software to be linked with XEmacs on one or more officially supported
platforms, it's '--with', otherwise, it's '--enable'."
Modules can
always be directly linked to XEmacs, so evaluate the rule at
--disable-modules.
So it's --enable-quick-build and --with-png. True, many platforms
come with X11 installed, but Mac OS X and Windows don't (and most
Linux distros require installing the dev packages), so it's
--with-x11.
The main one that I find confusing is widgets. Should it be
--enable-widgets --with-athena=3d, or should it be
--with-widgets=athena --with-athena=3d?
I tend to prefer the former, on the grounds that mixing and matching
widget sets is ugly and bug-prone, but in theory you can mix Athena
with Motif, and we do have the Lucid "native" widgets like the
menubar. So as a practical matter we may need to allow different
widget sets for menubar, dialogs, scrollbars, and widgets, implying
--with-menubar, --with-dialogs, --with-scrollbars, and --with-widgets.
I'm a little confused. What is the objection to just using `with-foo'
always, and never using `enable-foo' at all, no aliasing provided?
1:26 p.m.
On Wed, Sep 28, 2005 at 01:52:31AM -0500, Ben Wing wrote:
I'm a little confused. What is the objection to just using
`with-foo'
always, and never using `enable-foo' at all, no aliasing provided?
1- I'd find annoying to have to change my configure-calling scripts
_again_ (but I'll survive)
2- I really, really don't want us to have to go through that crap
again in 6-12 months. Always with-foo was the situation before
whoever changed it. So it must have not been the right thing for
some (unfathomable to me) reason.
OG.
1:53 p.m.
On 9/28/05, Olivier Galibert <galibert(a)pobox.com> wrote:
On Wed, Sep 28, 2005 at 01:52:31AM -0500, Ben Wing wrote:
> I'm a little confused. What is the objection to just using `with-foo'
> always, and never using `enable-foo' at all, no aliasing provided?
1- I'd find annoying to have to change my configure-calling scripts
_again_ (but I'll survive)
2- I really, really don't want us to have to go through that crap
again in 6-12 months. Always with-foo was the situation before
whoever changed it. So it must have not been the right thing for
some (unfathomable to me) reason.
OG.
While I agree with Ben that the current situation is confusing, I
don't think changing all of the --enables to --withs buys us very
much. It simplifies the situation at the expense of backwards
compatibility.
I think the autoconf distinction is, at best, confusing and in the
case of XEmacs, the distinctions don't make much sense. We are
clearly beyond the pale as far as number and types of options with
respect to autoconf.
We also have some history to consider: I, too, like Olivier, would not
want to change my scripts again.
Therefore, if we're going to make any changes, I think the only change
that increases understanding while respecting history is to create an
alias between --with and --enable.
My $.02.
- Vin
--
Whoever you are, no matter how lonely,
the world offers itself to your imagination,
calls to you like the wild geese, harsh and exciting--
over and over announcing your place
in the family of things. Mary Oliver
3:43 a.m.
Vin Shelton wrote:
On 9/28/05, Olivier Galibert <galibert(a)pobox.com> wrote:
>On Wed, Sep 28, 2005 at 01:52:31AM -0500, Ben Wing wrote:
>
>
>>I'm a little confused. What is the objection to just using `with-foo'
>>always, and never using `enable-foo' at all, no aliasing provided?
>>
>>
>1- I'd find annoying to have to change my configure-calling scripts
> _again_ (but I'll survive)
>
>2- I really, really don't want us to have to go through that crap
> again in 6-12 months. Always with-foo was the situation before
> whoever changed it. So it must have not been the right thing for
> some (unfathomable to me) reason.
>
> OG.
>
>
>
>
While I agree with Ben that the current situation is confusing, I
don't think changing all of the --enables to --withs buys us very
much. It simplifies the situation at the expense of backwards
compatibility.
backwards compatibility with what? we just redid all the options.
I think the autoconf distinction is, at best, confusing and in the
case of XEmacs, the distinctions don't make much sense. We are
clearly beyond the pale as far as number and types of options with
respect to autoconf.
right, that's exactly the reason to not make the distinctions.
We also have some history to consider: I, too, like Olivier, would
not
want to change my scripts again.
I really don't understand this. Changing your scripts is trivial:
perl -pi -e 's/-enable/-with/g;'
that's it.
1:19 p.m.
On 10/3/05, Ben Wing <ben(a)xemacs.org> wrote:
Vin Shelton wrote:
>While I agree with Ben that the current situation is confusing, I
>don't think changing all of the --enables to --withs buys us very
>much. It simplifies the situation at the expense of backwards
>compatibility.
>
>
backwards compatibility with what? we just redid all the options.
Believe it or not, I have a script that builds all XEmacsen from 19.16
to the present. I can actually build old 21.x tarballs using the same
script as a current tarball. Changing the options last time caused me
some grief, just as changing the options again will cause me some
grief. I assume that other people (many not on this list) will have
the same issue.
- Vin
--
Whoever you are, no matter how lonely,
the world offers itself to your imagination,
calls to you like the wild geese, harsh and exciting--
over and over announcing your place
in the family of things. Mary Oliver
7:23 a.m.
Vin Shelton wrote:
On 10/3/05, Ben Wing <ben(a)xemacs.org> wrote:
>Vin Shelton wrote:
>
>
>>While I agree with Ben that the current situation is confusing, I
>>don't think changing all of the --enables to --withs buys us very
>>much. It simplifies the situation at the expense of backwards
>>compatibility.
>>
>>
>>
>>
>backwards compatibility with what? we just redid all the options.
>
>
Believe it or not, I have a script that builds all XEmacsen from 19.16
to the present. I can actually build old 21.x tarballs using the same
script as a current tarball. Changing the options last time caused me
some grief, just as changing the options again will cause me some
grief. I assume that other people (many not on this list) will have
the same issue.
- Vin
i really think this is overblown. you're talking about backward
compatibility with something that was changed only a few betas ago. the
whole point of the beta process is not to be straitjacketed into
compatibility. if you really care about building *every* tarball,
you've already got a switch statement for various versions; adding
another statement and an associated s/-enable/-with/ is not hard.
keep in mind that reducing the randomness will be a *big* win for a
large number of XEmacs installers in the future. keeping it will make
life slightly easier for a dozen current users, at the expense of all
the others. (hell, if you really think it's going to be a burden, just
send me your scripts and i'll rewrite them for you.)
ben
12:58 p.m.
On 10/6/05, Ben Wing <ben(a)xemacs.org> wrote:
i really think this is overblown. you're talking about backward
compatibility with something that was changed only a few betas ago. the
whole point of the beta process is not to be straitjacketed into
compatibility. if you really care about building *every* tarball,
you've already got a switch statement for various versions; adding
another statement and an associated s/-enable/-with/ is not hard.
keep in mind that reducing the randomness will be a *big* win for a
large number of XEmacs installers in the future. keeping it will make
life slightly easier for a dozen current users, at the expense of all
the others. (hell, if you really think it's going to be a burden, just
send me your scripts and i'll rewrite them for you.)
Ben,
I realize my scripts can be fixed with some amount of programming. I
am not interested in your help, thank you.
I still think that aliasing '--with-foo' to '--enable-foo' makes the most
sense.
- Vin
1:27 p.m.
>>>> "Vin" == Vin Shelton
<ethersoft(a)gmail.com> writes:
Vin> I still think that aliasing '--with-foo' to '--enable-foo' makes
the most
Vin> sense.
The consensus seems to be in favour of aliasing, so I'll see what I can do
about coming up with a suitable patch.
Malcolm
--
Malcolm Purvis <malcolmp(a)xemacs.org>
5:42 a.m.
>>>> "Malcolm" == Malcolm Purvis
<malcolmp(a)xemacs.org> writes:
>>>> "Vin" == Vin Shelton
<ethersoft(a)gmail.com> writes:
Vin> I still think that aliasing '--with-foo' to '--enable-foo'
Vin> makes the most sense.
Malcolm> The consensus seems to be in favour of aliasing, so I'll
Malcolm> see what I can do about coming up with a suitable patch.
Please add code to warn loudly (both at version require time and in
Installation) if used with an untested version of Autoconf (ie > 2.59
currently). I really do not trust the Autoconf people to maintain the
semantic parallel.
--
School of Systems and Information Engineering 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.
6:05 p.m.
Vin Shelton wrote:
On 10/6/05, Ben Wing <ben(a)xemacs.org> wrote:
>i really think this is overblown. you're talking about backward
>compatibility with something that was changed only a few betas ago. the
>whole point of the beta process is not to be straitjacketed into
>compatibility. if you really care about building *every* tarball,
>you've already got a switch statement for various versions; adding
>another statement and an associated s/-enable/-with/ is not hard.
>
>keep in mind that reducing the randomness will be a *big* win for a
>large number of XEmacs installers in the future. keeping it will make
>life slightly easier for a dozen current users, at the expense of all
>the others. (hell, if you really think it's going to be a burden, just
>send me your scripts and i'll rewrite them for you.)
>
>
Ben,
I realize my scripts can be fixed with some amount of programming. I
am not interested in your help, thank you.
I still think that aliasing '--with-foo' to '--enable-foo' makes the most
sense.
sure, if someone who understands autoconf will go do it. i'm just
concerned that no one will actually do it, and since you don't want me
to just s/enable/with/ in configure.ac, we'll get stuck with the current
situation indefinitely.
6:35 p.m.
On Thu, Oct 06, 2005 at 12:05:20PM -0500, Ben Wing wrote:
sure, if someone who understands autoconf will go do it. i'm
just
concerned that no one will actually do it, and since you don't want me
to just s/enable/with/ in configure.ac, we'll get stuck with the current
situation indefinitely.
If we just s/enable/with/ as you say, what makes you think somebody
will not change some of them to enable again in six months
_like_it_has_already_happened_ ?
I want the aliasing because I do not want this crap to happen ever
again.
OG.
1:38 a.m.
Olivier Galibert wrote:
On Thu, Oct 06, 2005 at 12:05:20PM -0500, Ben Wing wrote:
>sure, if someone who understands autoconf will go do it. i'm just
>concerned that no one will actually do it, and since you don't want me
>to just s/enable/with/ in configure.ac, we'll get stuck with the current
>situation indefinitely.
>
>
If we just s/enable/with/ as you say, what makes you think somebody
will not change some of them to enable again in six months
_like_it_has_already_happened_ ?
I want the aliasing because I do not want this crap to happen ever
again.
ok. who understands autoconf well enough to do this?
2:07 p.m.
>>>> "Ben" == Ben Wing <ben(a)xemacs.org>
writes:
Ben> I'm a little confused. What is the objection to just using `with-foo'
Ben> always, and never using `enable-foo' at all, no aliasing provided?
The objection is: That's not the way autoconf 2.5X would like it done.
For the sake of comparison listed below are the configure options for XEmacs
21.5, GNU Emacs from CVS, Mozilla, xscreensaver and PostgreSQL. I chose these
because they're all fairly large and complex packages.
Mozilla tends to prefer --enable while the rest have a larger proportion of
--with. Selecting a X toolkit can be either, but in other areas our choices
are not too dissimilar to existing practise.
However this list does show is that we have a very large number of options,
especially compared to GNU Emacs. Do we need them all?
From a technical perspective, autoconf 2.5X will support the exclusive
use of
--with just fine and won't cause our configuration script any extra
problems
when we upgrade. Autoconf 2.5X documentation and culture prefer using --with
and --enable. Which way shall we go?
Malcolm
---------------------------------------------------------------------------
XEmacs:
--enable-mule
--enable-default-eol-detection
--enable-external-widget
--enable-kkcc Enable new GC algorithms.
--enable-mc-alloc Enable new allocator.
--enable-union-type
--enable-pdump Enable portable LISP preloader.
--enable-dump-in-exec
--enable-debug Enable additional debugging information. No time
cost.
--enable-assertions
--enable-memory-usage-stats
Enable LISP memory usage API.
--enable-clash-detection
--enable-modules
--enable-quick-build
--enable-database=TYPE
--enable-sound=TYPE
--enable-bignum=TYPE
--enable-error-checking=TYPE
--enable-menubars=TYPE
--enable-scrollbars=TYPE
--enable-dialogs=TYPE
--enable-widgets=TYPE
--enable-toolbars Enable toolbar support. Default: yes.
--with-prefix=no
--with-site-lisp=no
--with-site-modules
--with-gtk Support GTK on the X Window System. (EXPERIMENTAL)
--with-gnome Support GNOME on the X Window System. (EXPERIMENTAL)
--with-msw
--with-gcc Use GCC to compile XEmacs.
--with-dynamic
--with-ncurses Use the ncurses library for tty support.
--with-dnet Compile with support for DECnet.
--with-socks Compile with support for SOCKS (an Internet proxy).
--with-dragndrop
--with-cde Compile in support for CDE drag and drop.
--with-offix
--with-gpm Compile in GPM mouse support for ttys.
--with-xpm
--with-xface Compile with support for X-Face mail headers.
Requires the compface package.
--with-gif
--with-jpeg
--with-png
--with-tiff
--with-zlib Support inflate (de)compression internally.
--with-wmcommand
--with-xmu Use Xmu utilities. Default: yes.
--with-purify Support memory debugging using Purify.
--with-quantify Support performance debugging using Quantify.
--with-tty Enable TTY support. Default: yes.
--with-xfs
--with-canna
--with-wnn
--with-wnn6
--with-workshop
--with-sparcworks Alias for --with-workshop
--with-tooltalk Support the ToolTalk IPC protocol.
--with-ldap Support the LDAP protocol.
--with-postgresql Support the PostgreSQL RDBMS.
--with-pop Support POP for mail retrieval.
--with-kerberos Support Kerberos-authenticated POP.
--with-hesiod Support Hesiod to get the POP server host.
--with-infodock Support the Infodock version of XEmacs. Infodock is
a SourceForge project).
--with-native-sound-lib Path to sound library (for systems with name
conflicts).
--with-netinstall Support for installation over the internet. Only
functional on the MS Windows platforms.
--with-optimization
--with-ipv6-cname
--with-site-includes Prepend to include search path.
--with-site-libraries Prepend to library search path.
--with-site-prefixes
--with-statedir
--with-lispdir
--with-archlibdir
--with-moduledir
--with-etcdir
--with-infopath
--with-docdir
--with-site-runtime-libraries
--with-package-prefix Specify packages root.
--with-package-path Search path for package hierarchies.
--with-compiler C compiler to use
--with-xemacs-compiler
--with-cflags
--with-cflags-warning
--with-cflags-optimization=FLAGS
--with-cflags-debugging=FLAGS
--with-cpp
--with-cppflags C preprocessor flags (e.g. -I/foo or -Dfoo=bar)
--with-libs Additional libraries (e.g. -lfoo)
--with-ldflags Additional linker flags (e.g. -L/foo)
--with-rel-alloc Enable the relocating allocator.
--with-dlmalloc Use Doug Lea's malloc implementation.
--with-debug-malloc Use a debugging malloc.
--with-system-malloc
--with-athena Use TYPE Athena widgets (xaw, 3d, next, 95, or xpm).
--with-mail-locking=TYPE
--with-x use the X Window System
---------------------------------------------------------------------------
Emacs:
--enable-carbon-app[=DIR] [DIR=/Application]
specify install directory for Emacs.app on Mac OS X
--enable-asserts compile code with asserts enabled
--enable-maintainer-mode enable make rules and dependencies not useful
(and sometimes confusing) to the casual installer
--enable-locallisppath=PATH
directories Emacs should search for lisp files
specific to this site
--disable-largefile omit support for large files
--without-gcc don't use GCC to compile Emacs if GCC is found
--without-pop don't support POP mail retrieval with movemail
--with-kerberos support Kerberos-authenticated POP
--with-kerberos5 support Kerberos version 5 authenticated POP
--with-hesiod support Hesiod to get the POP server host
--without-sound don't compile with sound support
--with-x-toolkit=KIT use an X toolkit
(KIT = yes/lucid/athena/motif/gtk/no)
--with-xpm use -lXpm for displaying XPM images
--with-jpeg use -ljpeg for displaying JPEG images
--with-tiff use -ltiff for displaying TIFF images
--with-gif use -lungif for displaying GIF images
--with-png use -lpng for displaying PNG images
--with-gtk use GTK (same as --with-x-toolkit=gtk)
--with-pkg-config-prog Path to pkg-config to use for finding GTK
--without-toolkit-scroll-bars
don't use Motif or Xaw3d scroll bars
--without-xim don't use X11 XIM
--without-carbon don't use Carbon GUI on Mac OS X
--with-x use the X Window System
---------------------------------------------------------------------------
Mozilla:
--disable-freetypetest
Do not try to compile and run a test FreeType program
--enable-macos-target=VER (default=10.1)
Set the minimum MacOS version needed at runtime
--enable-default-toolkit=TK
Select default toolkit
Platform specific defaults:
BeOS - beos
Mac OS X - mac (carbon)
Neutrino/QNX - photon
OS/2 - os2
Win32 - windows
* - gtk
--disable-gtktest Do not try to compile and run a test GTK program
--enable-calendar Enable building of the calendar client
--disable-mailnews Disable building of mail & news components
--enable-static-mail Enable static mail build support
--disable-ldap Disable LDAP support
--enable-official-branding Enable Official Branding
--disable-freetype2 Disable FreeType2 support
--enable-xft Enable Xft support
--disable-postscript Disable PostScript printing support
--disable-xprint Disable Xprint printing support
--disable-gnomevfs Disable GnomeVFS support
--enable-crypto Enable crypto support (Personal Security Manager)
--disable-jsd Disable JavaScript debug library
--disable-oji Disable Open JVM Integration support
--enable-xinerama Enable Xinerama support
( not safe for Red Hat 7.0 )
--enable-ctl Enable Thai Complex Script support
--disable-view-source Disable view source support
--disable-accessibility Disable accessibility support
--disable-xpfe-components
Disable xpfe components
--disable-xpinstall Disable xpinstall support
--enable-single-profile Enable single profile support
--disable-jsloader Disable xpcom js loader support
--enable-native-uconv Enable iconv support
--enable-plaintext-editor-only
Allow only plaintext editing
--disable-composer Disable building of Composer
--enable-extensions Enable extensions
--enable-image-decoders[={mod1,mod2,default,all,none}]
Enable specific image decoders
--enable-ldap-experimental
Enable LDAP experimental features
--disable-mathml Disable MathML support
--enable-svg Enable SVG support
--enable-svg-renderer-gdiplus Enable SVG gdi+ renderer
--enable-svg-renderer-libart Enable SVG libart renderer
--enable-svg-renderer-cairo Enable SVG cairo renderer
--disable-installer Disable building of installer
--disable-activex Disable building of ActiveX control (win32 only)
--disable-activex-scripting
Disable building of ActiveX scripting support (win32)
--enable-leaky Build leaky memory tool
--enable-xpctools Build JS profiling tool
--disable-tests Do not build test libraries & programs
--enable-xpcom-lea Use Lea malloc in xpcom
--enable-js-ultrasparc Use UltraSPARC optimizations in JS
--disable-debug Disable building with debug info
--enable-optimize[=OPT] Enable optimizations using compiler flags [OPT=-O]
--enable-debug-modules Enable/disable debug info for specific modules
--enable-debugger-info-modules
Enable/disable debugger info for specific modules
--enable-boehm Enable the Boehm Garbage Collector
--disable-logging Disable logging facilities
--enable-crash-on-assert
Make NS_ASSERTION crash on Unix
--enable-reorder Enable function reordering (requires GNU ld)
--enable-logrefcnt Enable logging of refcounts (default=debug)
--enable-detect-webshell-leaks
Enable detection of webshell leaks
(default=debug)
--enable-wrap-malloc Wrap malloc calls (gnu linker only)
--enable-efence Link with Electric Fence
--enable-jprof Enable jprof profiling tool (needs mozilla/tools/jprof)
--enable-strip Enable stripping of libs & executables
--enable-elf-dynstr-gc Enable elf dynstr garbage collector (opt builds only)
--enable-old-abi-compat-wrappers
Support old GCC ABI symbols to ease the pain
of the linux compiler change
--enable-prebinding Enable prebinding (Mac OS X only)
--enable-timeline Enable timeline services
--enable-reflow-perf Enable reflow performance tracing
--enable-perf-metrics Enable performance metrics
--enable-codesighs Enable code size analysis tools
--enable-trace-malloc Enable malloc tracing
--enable-eazel-profiler-support
Enable Corel/Eazel profiler support
--enable-profile-modules
Enable/disable profiling for specific modules
--enable-insure Enable insure++ instrumentation (linux only)
--enable-quantify Enable Quantify support (Windows only)
--enable-xterm-updates Update XTERM titles with current command.
--enable-chrome-format=jar|flat|both|symlink
Select FORMAT of chrome files (default=jar)
--enable-long-long-warning
Warn about use of non-ANSI long long type
--disable-pedantic Issue all warnings demanded by strict ANSI C
--enable-cpp-rtti Enable C++ RTTI
--enable-cpp-exceptions Enable C++ exceptions
--disable-auto-deps Do not automatically generate dependency info
--disable-md Do not use compiler-based dependencies
--disable-shared Disable building of internal shared libs
--enable-static Enable building of internal static libs
--disable-static-component-loader
Disable the static component loader
--enable-meta-component-modules=mod1[,mod2]
Build single meta-component from specified modules
--enable-meta-components
Build predefined meta-components
--enable-componentlib Build a shared library containing all of the components
--enable-standalone-modules=mod1[,mod2]
Enable standalone build of specific modules
--disable-libIDLtest Do not try to compile and run a test libIDL program
--disable-glibtest Do not try to compile and run a test GLIB program
--disable-glibtest Do not try to compile and run a test GLIB program
--disable-xul Disable XUL
--disable-profilesharing Disable profile sharing
--disable-profilelocking Disable profile locking
--enable-necko-protocols[={http,ftp,default,all,none}]
Enable/disable specific protocol handlers
--disable-necko-disk-cache
Disable necko disk cache
--enable-necko-small-buffers
Minimize size of necko's i/o buffers
--with-macos-sdk=dir Location of platform SDK to use (Mac OS X only)
--with-x use the X Window System
--with-ft-prefix=PFX Prefix where FreeType is installed (optional)
--with-ft-exec-prefix=PFX
Exec prefix where FreeType is installed (optional)
--with-pthreads Force use of system pthread library with NSPR
--with-system-nspr Use system installed NSPR
--with-nspr-prefix=PFX Prefix where NSPR is installed
--with-nspr-exec-prefix=PFX
Exec prefix where NSPR is installed
--with-system-jpeg[=PFX]
Use system libjpeg [installed at prefix PFX]
--with-system-zlib[=PFX]
Use system libz [installed at prefix PFX]
--with-system-png[=PFX]
Use system libpng [installed at prefix PFX]
--with-gtk-prefix=PFX Prefix where GTK is installed (optional)
--with-gtk-exec-prefix=PFX
Exec prefix where GTK is installed (optional)
--with-gssapi=PFX Location of GSSAPI libraries
--with-wrap-malloc=DIR Location of malloc wrapper library
--with-insure-dirs=DIRS
Dirs to instrument with insure
--with-insure-exclude-dirs=DIRS
Dirs to not instrument with insure
--with-default-mozilla-five-home
Set the default value for MOZILLA_FIVE_HOME
--with-user-appdir=DIR Set user-specific appdir (default=.mozilla)
--with-doc-input-dirs=DIRS
Header/idl dirs to create docs from
--with-doc-include-dirs=DIRS
Include dirs to preprocess doc headers
--with-doc-output-dir=DIR
Dir to generate docs into
--without-libIDL Skip check for libIDL (standalone modules only)
--with-libIDL-prefix=PFX
Prefix where libIDL is installed (optional)
--with-libIDL-exec-prefix=PFX
Exec prefix where libIDL is installed (optional)
--with-glib-prefix=PFX Prefix where GLIB is installed (optional)
--with-glib-exec-prefix=PFX
Exec prefix where GLIB is installed (optional)
--with-glib-prefix=PFX Prefix where GLIB is installed (optional)
--with-glib-exec-prefix=PFX
Exec prefix where GLIB is installed (optional)
---------------------------------------------------------------------------
xscreensaver:
--enable-locking Compile in support for locking the display.
--disable-locking Do not allow locking at all.
--with-hackdir=DIR Where to install the hundreds of demo executables.
Default: `EPREFIX/lib/xscreensaver/'
--with-configdir=DIR Where to install the data files that describe each
of the display modes to the GUI.
Default: `PREFIX/share/xscreensaver/config/'
--with-sgi-ext Include support for the SGI SCREEN_SAVER extension.
--with-xidle-ext Include support for the XIDLE extension.
--with-sgivc-ext Include support for the SGI-VIDEO-CONTROL extension.
--with-dpms-ext Include support for the DPMS extension.
--with-xinerama-ext Include support for the XINERAMA extension.
--with-xf86vmode-ext Include support for XFree86 virtual screens.
--with-xf86gamma-ext Include support for XFree86 gamma fading.
--with-randr-ext Include support for the X Resize+Rotate extension.
--with-proc-interrupts Include support for consulting the /proc/interrupts
file to notice keyboard activity.
--with-pam Include support for PAM (Pluggable Auth Modules.)
--with-kerberos Include support for Kerberos authentication.
--with-shadow Include support for shadow password authentication.
--with-passwd-helper Include support for an external password
verification helper program.
--with-login-manager Put a "New Login" button on the unlock dialog that
--with-gtk Use the Gtk toolkit for the user interface.
--with-motif Use the Motif toolkit for the user interface
--with-gl Build those demos which depend on OpenGL.
--with-gle Build those demos which depend on GLE
(the OpenGL "extrusion" library.)
--with-pixbuf Include support for the GDK-Pixbuf library in some
demos, which will make it possible for them to read
GIF, JPEG, and PNG files as well.
--with-xpm Include support for XPM files in some demos.
(Not needed if Pixbuf is used.)
--with-jpeg Include support for the JPEG library.
--with-xshm-ext Include support for the Shared Memory extension.
--with-xdbe-ext Include support for the DOUBLE-BUFFER extension.
--with-readdisplay Include support for the XReadDisplay extension.
--with-image-directory=DIR By default, some screen savers may load
random images out of this directory.
--with-setuid-hacks Allow some demos to be installed `setuid root'
(which is needed in order to ping other hosts.)
---------------------------------------------------------------------------
PostgreSQL:
Optional Features:
--enable-integer-datetimes enable 64-bit integer date/time support
--enable-nls[=LANGUAGES] enable Native Language Support
--disable-shared do not build shared libraries
--disable-rpath do not embed shared library search path in executables
--disable-spinlocks do not use spinlocks
--enable-debug build with debugging symbols (-g)
--enable-depend turn on automatic dependency tracking
--enable-cassert enable assertion checks (for debugging)
--enable-thread-safety make client libraries thread-safe
--enable-thread-safety-force force thread-safety in spite of thread test failure
--disable-largefile omit support for large files
Optional Packages:
--with-docdir=DIR install the documentation in DIR [PREFIX/doc]
--without-docdir do not install the documentation
--with-includes=DIRS look for additional header files in DIRS
--with-libraries=DIRS look for additional libraries in DIRS
--with-libs=DIRS alternative spelling of --with-libraries
--with-pgport=PORTNUM change default port number 5432
--with-tcl build Tcl modules (PL/Tcl)
--with-tclconfig=DIR tclConfig.sh is in DIR
--with-perl build Perl modules (PL/Perl)
--with-python build Python modules (PL/Python)
--with-krb4 build with Kerberos 4 support
--with-krb5 build with Kerberos 5 support
--with-krb-srvnam=NAME name of the service principal in Kerberos [postgres]
--with-pam build with PAM support
--with-rendezvous build with Rendezvous support
--with-openssl build with OpenSSL support
--without-readline do not use Readline
--without-zlib do not use Zlib
--with-gnu-ld assume the C compiler uses GNU ld [default=no]
---------------------------------------------------------------------------
--
Malcolm Purvis <malcolmp(a)xemacs.org>
5:05 a.m.
>>>> "Malcolm" == Malcolm Purvis
<malcolmp(a)xemacs.org> writes:
Malcolm> However this list does show is that we have a very large
Malcolm> number of options, especially compared to GNU Emacs. Do
Malcolm> we need them all?
Yes, until all those things get modularized.
--
School of Systems and Information Engineering 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.
7098
days inactive
7109
days old
27 comments
8 participants
participants (8)
-
Adrian Aichner -
Ben Wing -
Ben Wing -
Hrvoje Niksic -
Malcolm Purvis -
Olivier Galibert -
Stephen J. Turnbull -
Vin Shelton