"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Sorry, I'm missing context: What's "its" and what would be the "default"? Exactly. If they aren't set via configure, XEmacs activates its run-time searching kung-fu. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Thursday 12 March 2009, Stephen J. Turnbull wrote: I'm not quite following why it should be testing whether it expands to the default - INFODIR_USER_DEFINED sounds to me like "did the user define it?". If the user did define it, just use what the user told no matter what it is (default or not), otherwise fall back to the built-in lookup would sound better to me. This works for me (although my builds (done with rpm) always do set both --prefix and --infodir): -if test "x$infodir_expanded" != "x${prefix_expanded}/share/info" +if test "x$infodir" != 'x${datarootdir}/info' Note the single quotes in the latter. It isn't bullet proof against doing ./configure --infodir='${datarootdir}/info' (again single quotes or otherwise getting literal, unexpanded ${datarootdir}/info passed to configure) but... meh. If the above interpretation is "correct", I think the same changes should be applied to the similar $datadir_expanded and $libdir_expanded tests above the infodir one. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Saturday 14 March 2009, Michael Sperber wrote: I think it's safe enough to assume that if infodir is ${datarootdir}/info (note: literal, _unexpanded_, do *not* check /usr/share/info or /usr/local/share/info) by the time we examine its value, it was not set by the user. Or even more generally, if its value contains a $, it was not set by the user. Yes, and this is why I think looking at the expanded value is fundamentally flawed approach for what I understand the purpose of the code in configure.ac is. I'm afraid I don't follow you here. I'm not trying to change any defaults here. See above and my previous mail - the key thing to understand in my proposal is checking for the _unexpanded_ default values. By the way, configure.ac already has the defaults mixed up, although it will probably trigger quite rarely. configure has infodir='${datarootdir}/info' but configure.ac (and thus configure) tests ${prefix_expanded}/share/info to see if infodir is set to the default value. It should test for ${datarootdir_expanded}/info instead. But this wouldn't be useful for solving the problem I have, see above for a IMO better way (checking unexpanded values) to fix it. I think there's a bunch of things in configure.ac that should just go away. We use autoconf, so we should really just use it and not fight against how it works without a very good reason. And in the places we want to kludge around its usual behavior, the wanted behavior and the reason for it needs to be documented. I could spend some time trying to clean things up but without documentation why the kludges exist, doing so would lead to "bikeshed discussions". BTW I still don't see value in the *_USER_DEFINED logic. Just use values from autoconf no matter how they were set, and adapt built in path lookup code for various dirs to use it _and_ additionally do internal lookup wherever needed would sound like a saner approach to me. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Ville Skyttä writes: It doesn't. For XE_MERGED_ARGs it would be easy to add in the m4 definition. For the *dir variables, which are mostly builtin to autoconf, initialize each to "xe_placeholder_for_builtin_options", then add if test $OPTION=xe_placeholder_for_builtin_options; then OPTION_user_defined=no OPTION=DEFAULT_VALUE_FOR_OPTION else OPTION_user_defined=yes fi for each OPTION at about where the stray 'with_dragndrop_default="no"' is now (so that it comes after the built-in options processor). I disagree. autoconf is nowhere near powerful enough to do what we need it to do in terms of options processing, and it gets weaker with every release as they add more checks and more bogus runtime warnings. That's where most of the "fighting" is happening: trying to allow people to specify stuff without having to add millions of additional options. Examples of undocumented differences? I hope you're not referring to XE_MERGED_ARG and XE_COMPLEX_OPTION. (You're welcome to argue they're unnecessary, but IMO they are copiously commented and include rationale, which is not all that difficult to guess in the first place.) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Ville Skyttä writes: You'll have to get Mike to discuss that. He insists that things be done as they are, but I've never personally had any reason to care one way or the other (no personal config problems, no need for the features he added, and I don't recall ever getting user questions either). [The package hierarchy configuration is a different matter, that has been controversial since the release of 21.4.0 IIRC.] The rationale is that "standard settings for standard variables" don't work. The GNU utilities in lib-src can't be compiled as C++, for example, and some commonly used options for C and C++ are not shared with the other. These --with-build-option flags are basically developer options, for people who want to build with C++ to get the benefits of better static type-checking and the like, or who want to turn optimization off in XEmacs but not in the utilities. These flags allow fairly flexible merging and sanity checking of configurations used by developers. If you're build a production XEmacs, I would assume that you use C, and the same build environment for both XEmacs and the lib-src utilities probably makes the best sense. AFAIK the default settings of the --with-build-option options are transparent to the usual environment variables. If that's not true it's a bug and should be fixed. Probably those options should just be documented as "for developers only; production builds should use the traditional environment variables". AFAIK that's lossage from the autoconf 2.13 -> autoconf 2.5x transition. The autoconf people decided that only built-in options can do without the --with (or --enable) prefix, but they also decided that FHS standard hierarchy would be enforced this way, and that they would change some of the traditional names. That turned out to be very unfriendly to non-Linux systems and users, who were supported by migrating the old familiar names that autoconf no longer supports to --with variants. Ie, if --statedir doesn't work, then --with-statedir will. Probably after several years of this policy by autoconf, everybody's more or less used to the new terminology and we could do without the bandaids, but anybody who submits a patch to rationalize the user- visible options is going to need to be around on c.e.x and xemacs-beta to hold hands of users whose build scripts fail when the options they use disappear or start doing something different. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: Of course the option itself is a holdover. But my understanding is that by "undocumented difference from autoconf" he's referring to INFODIR_USER_DEFINED, and the catering to run-in-place and people who schlep whole installed trees around and other cases that you won't encounter in an RPM install. Ville? _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Please use issue508 for this issue. Ville Skyttä writes: AFAICT, all of the problems have two root causes: (1) failure to sync the various values that are related to the --infodir option (basically these are typos), and (2) INFODIR_USER_DEFINED handling (what you call foo_expanded stuff). It is not intended that the various values mentioned in the default at the top of configure.ac, in the docstring for the option, and in the check for INFODIR_USER_DEFINED be different. But it's not clear what to set them to until we decide how to handle INFODIR_USER_DEFINED. Once we do decide, it will be easy to fix. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta