Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 05/22/2013 11:43 AM, Mike Frysinger wrote: my point for keeping the automatic search behavior is so that people don't have to pour through --help output and set yet-more esoteric variables so things just work. you're of course right that by having two variables results in dirt simple code on the implementation side. but the end user experience is terrible. however, adding a patch search, while is more code, is not complicated, and both the end user and distros win. the code could even be made simpler if we throw out the --time-stamp check and accept things based purely on their name. simply leverage AC_PATH_PROG. Maybe you have a point there. Basically, I'd like $CONFIG_GUESS to behave like $CC, and maybe searching the user's PATH is worth trying first, falling back to our in-tree version if a path search turns up nothing, and where the env-var always takes precedence. I still don't think we need to hard-code any additions to the user's path. After all, the ONLY time that using a newer config.guess will help you is when porting to a new machine type that was not present in an older config.guess; but if you argue that the first thing a distro does when preparing a port to a new machine triple is to install an updated /usr/bin/config.guess, then that will be sufficient to let all the other new enough packages automatically find the right triple. Even if /usr/bin/config.guess is older than the one bundled with an (even newer) package, it is still new enough to support the target triple on which you are compiling that package. So favoring a PATH lookup over the in-tree version should always work, and falling back to the in-tree version instead of outright failing should work for all situations where config.guess is not installed on the user's PATH. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Thursday 23 May 2013 10:31:26 Eric Blake wrote: On 05/22/2013 11:43 AM, Mike Frysinger wrote: my point for keeping the automatic search behavior is so that people don't have to pour through --help output and set yet-more esoteric variables so things just work. you're of course right that by having two variables results in dirt simple code on the implementation side. but the end user experience is terrible. however, adding a patch search, while is more code, is not complicated, and both the end user and distros win. the code could even be made simpler if we throw out the --time-stamp check and accept things based purely on their name. simply leverage AC_PATH_PROG. Maybe you have a point there. Basically, I'd like $CONFIG_GUESS to behave like $CC, and maybe searching the user's PATH is worth trying first, falling back to our in-tree version if a path search turns up nothing, and where the env-var always takes precedence. I still don't think we need to hard-code any additions to the user's path. After all, the ONLY time that using a newer config.guess will help you is when porting to a new machine type that was not present in an older config.guess; but if you argue that the first thing a distro does when preparing a port to a new machine triple is to install an updated /usr/bin/config.guess, then that will be sufficient to let all the other new enough packages automatically find the right triple. Even if /usr/bin/config.guess is older than the one bundled with an (even newer) package, it is still new enough to support the target triple on which you are compiling that package. So favoring a PATH lookup over the in-tree version should always work, and falling back to the in-tree version instead of outright failing should work for all situations where config.guess is not installed on the user's PATH. i don't think anyone installs these things into $PATH today. we put them into /usr/share/ somewhere. the idea with the custom path search was so that you didn't need to be running a good distro for this stuff to work ... it would work with any system that follows default libtool/automake install conventions. i misread the patch and what it was doing with --timestamp. the point was to make sure it didn't inadvertently select an older version. so i guess i'm in favor of the current (more complicated) version :/. the automake-1.12+ has a --print-libdir option. what if we use that rather than hardcoding the automake paths ? if we're all in agreement with the $CONFIG_SUB / $CONFIG_GUESS starting point, maybe we merge that now and continue debating the extended points ? -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
It's what I've done for years. Does it get rid of the problem? I don't think so but for legacy code that is no longer being maintained, either you maintain it, or the problem exists into infinity with a hard stop when someone does maintain it. I think the battle is trying to overcome continuing the legacy method of needing to replace config.guess/config.sub within a package and allow a common (or configurable) location be used as new development takes place. The http://lists.gnu.org/archive/html/autoconf/2013-05/msg00069.html is probably what you are talking about. I like this idea too, but these two ideas are not overlapping, IMO. From that thread: Maybe have a common directory of /usr/[local/]share/autoconf/auxdir and teach autoconf to look there if it doesn't find Even if we were able to teach in future our ./configure scripts (not autoconf — as autoreconf -vfi actually solves this even now by calling automake) to look into some configurable place using special option, the ENV VAR solution _may still co-exist_ (and should have always the highest priority). Pavel ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tuesday 21 May 2013 09:57:32 Jan Engelhardt wrote: On Tuesday 2013-05-21 07:33, Pavel Raiskup wrote: Works for me. But we [distros] do want to mandate autoreconf anyway in the general case: it is the *only* way to keep upstream honest about the much hated build system not bitrotting until it decides to blow up right when we need it for a security update. I know. But there is a lot of tarballs not able to be easily autoreconf-ed (more than 10 years old) and not having upstream.. and it needs a lot of changes downstream before autoreconf successes.. (and you need to have a quite good knowledge about auto-toolset). If upstream is dead, the distros should perhaps reevaluate whether to drop the package or de facto become upstream by a process of adoption. that's might sound great, but really doesn't line up with reality. distros are chronically understaffed and becoming defacto upstreams for every random package that goes dormant/dead and can't survive an `autoreconf` isn't viable. -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Monday 20 May 2013 10:37:00 Eric Blake wrote: On 05/18/2013 05:45 AM, Paul Wise wrote: On Fri, 2013-05-17 at 16:05 -0300, Henrique de Moraes Holschuh wrote: Yes. It would have been really useful if autofoo used whatever is in /usr/share/misc, unless there is a config.sub.override or config.guess.override file in the source directory (or even better, something pointed to by environment variables), and deprecate source-directory config.guess and config.sub. My original patch didn't allow overrides, here is an updated one. I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB environment variable, rather than baking in a PATH search. This topic has come up in the past, where I made the same request back then. this might be sufficient for distro packagers (once they're in the know that they have to export these two), but that doesn't help people who download arbitrary packages and run `./configure` themselves. what if the autoconf macros grew a new option/macro so that in the very uncommon case that someone has written their own, they could explicitly declare so ? AC_CANONICAL_CUSTOM this would disable the custom search path and only respect the env vars -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Saturday 18 May 2013 07:45:54 Paul Wise wrote: On Fri, 2013-05-17 at 16:05 -0300, Henrique de Moraes Holschuh wrote: Yes. It would have been really useful if autofoo used whatever is in /usr/share/misc, unless there is a config.sub.override or config.guess.override file in the source directory (or even better, something pointed to by environment variables), and deprecate source-directory config.guess and config.sub. My original patch didn't allow overrides, here is an updated one. +AC_DEFUN([AC_CONFIG_AUX_DIR, pretty sure you're missing a closing ] there +/usr/share/gnuconfig \ if you post another revision, just delete this path. i think Gentoo is the only one that uses this, and one of the other paths will catch us. -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 05/22/2013 10:22 AM, Mike Frysinger wrote: I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB environment variable, rather than baking in a PATH search. This topic has come up in the past, where I made the same request back then. this might be sufficient for distro packagers (once they're in the know that they have to export these two), but that doesn't help people who download arbitrary packages and run `./configure` themselves. what if the autoconf macros grew a new option/macro so that in the very uncommon case that someone has written their own, they could explicitly declare so ? AC_CANONICAL_CUSTOM this would disable the custom search path and only respect the env vars I still don't see why you are overengineering things. Make the env-var precious - then it will show up in ./configure --help output, and be preserved so that ./config.status --config will show you what it was set to at the time. If the only way to get the override is via an env-var, then there is no need for the complexity of either a baked-in path search nor a means of letting SOME packages disable the complexity of a baked-in path search. If you can argue that SOME packages will want to disable the complexity, then I can argue that we should make the default of disabled complexity be everywhere. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Wednesday 22 May 2013 12:27:38 Eric Blake wrote:
On 05/22/2013 10:22 AM, Mike Frysinger wrote:
I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB
environment variable, rather than baking in a PATH search. This topic
has come up in the past, where I made the same request back then.
this might be sufficient for distro packagers (once they're in the know
that they have to export these two), but that doesn't help people who
download arbitrary packages and run `./configure` themselves.
what if the autoconf macros grew a new option/macro so that in the very
uncommon case that someone has written their own, they could explicitly
declare so ?
AC_CANONICAL_CUSTOM
this would disable the custom search path and only respect the env vars
I still don't see why you are overengineering things. Make the env-var
precious - then it will show up in ./configure --help output, and be
preserved so that ./config.status --config will show you what it was set
to at the time. If the only way to get the override is via an env-var,
then there is no need for the complexity of either a baked-in path
search nor a means of letting SOME packages disable the complexity of a
baked-in path search. If you can argue that SOME packages will want to
disable the complexity, then I can argue that we should make the default
of disabled complexity be everywhere.
i don't have a problem throwing out support for custom config.{guess,sub}
files.
as noted elsewhere in this thread, i believe that to be an obsolete art.
my point for keeping the automatic search behavior is so that people don't
have to pour through --help output and set yet-more esoteric variables so
things just work. you're of course right that by having two variables
results in dirt simple code on the implementation side. but the end user
experience is terrible. however, adding a patch search, while is more code,
is not complicated, and both the end user and distros win.
the code could even be made simpler if we throw out the --time-stamp check and
accept things based purely on their name. simply leverage AC_PATH_PROG.
-mike
signature.asc
Description: This is a digitally signed message part.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, May 20, 2013 at 02:54:20PM +0800, Paul Wise wrote: There are thousands of copies of config.guess/sub (or configure scripts) out there (in tarballs) with no support for this at all. Once it is added to config.guess/sub in git (or autoconf) then it will take many years before the majority of copies of config.guess/sub (or configure scripts) have support for this. This is what I mean by bootstrap phase. Right. Just thinking out loud: isn't the Autoconf concept of aux dir of use here? That's where configure looks for config.guess. The latest version of install-sh, config.guess, etc. could live in such a system-wide directory. Unfortunately, it's not possible to set auxdir from the configure command line as you can with --srcdir, etc. Ben signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
When it comes to people building distro packages, here is another idea
thinking out loud. What's wrong with ..
$ find /tree/of/src/trees -name config.guess -exec ln -sf /etc/config.guess {}
\;
This puts the latest version into the tree, no patching required.
Ben
signature.asc
Description: Digital signature
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 2:34 AM, Ben Elliston wrote: On Mon, May 20, 2013 at 02:54:20PM +0800, Paul Wise wrote: There are thousands of copies of config.guess/sub (or configure scripts) out there (in tarballs) with no support for this at all. Once it is added to config.guess/sub in git (or autoconf) then it will take many years before the majority of copies of config.guess/sub (or configure scripts) have support for this. This is what I mean by bootstrap phase. Right. Just thinking out loud: isn't the Autoconf concept of aux dir of use here? That's where configure looks for config.guess. The latest version of install-sh, config.guess, etc. could live in such a system-wide directory. Unfortunately, it's not possible to set auxdir from the configure command line as you can with --srcdir, etc. Maybe have a common directory of /usr/[local/]share/autoconf/auxdir and teach autoconf to look there if it doesn't find config.guess/config.sub in the project directory and copy them when copy is specified? I dislike the environment variable idea. Too fragile, someone forgets it is set and then has trouble because the config.guess/config.sub he's trying to use isn't being used. I know you mean for the variable to be set at autoreconf/configure usage but there are always idiots who install it into their .profile files and forget they did that. -- Earnie -- https://sites.google.com/site/earnieboyd ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 7:09 AM, Ben Elliston wrote:
When it comes to people building distro packages, here is another idea
thinking out loud. What's wrong with ..
$ find /tree/of/src/trees -name config.guess -exec ln -sf /etc/config.guess
{} \;
People forgetting about the symlink during distribution of their
package. Not all systems support it. Using cp -f would be better.
This puts the latest version into the tree, no patching required.
I tend to use a sub module repository and have config.guess and
config.sub in a directory (build-aux/) and I tell autoconf via
configure.ac where to find it.
--
Earnie
-- https://sites.google.com/site/earnieboyd
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 07:56:47AM -0400, Earnie Boyd wrote: if [[ -f /usr/local/share/config/config.guess ]] then . /usr/local/share/config/config.guess exit fi First, this does not solve the problem because it requires that every package get a new version of config.guess. We're trying to overcome having to modify every package. Second, I don't like the idea of doing things that surprise users. That will confuse people. Cheers, Ben signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 07:33:49AM -0400, Earnie Boyd wrote: People forgetting about the symlink during distribution of their package. Not all systems support it. Using cp -f would be better. OK, fine. :-) I think there are a few different use cases people have in mind. My understanding of the issue is that people responsible building large numbers of autoconfiscated packages for distros (eg, Debian) are the ones with the real headaches. I tend to use a sub module repository and have config.guess and config.sub in a directory (build-aux/) and I tell autoconf via configure.ac where to find it. Yes, but that requires re-running autoconf. I think we're trying to avoid that because if configure.in is old, you may have a lot of work to do to get autoreconf to work. Ben signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 7:36 AM, Ben Elliston wrote: Yes, but that requires re-running autoconf. I think we're trying to avoid that because if configure.in is old, you may have a lot of work to do to get autoreconf to work. So in that case, a change to the start of config.guess and config.sub something similar to the following might be best? ~ if [[ -f /usr/local/share/config/config.guess ]] then . /usr/local/share/config/config.guess exit fi if [[ -f /usr/share/config/config.guess ]] then . /usr/share/config/config.guess exit fi -- Earnie -- https://sites.google.com/site/earnieboyd ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 7:59 AM, Ben Elliston wrote: First, this does not solve the problem because it requires that every package get a new version of config.guess. We're trying to overcome having to modify every package. So that's your objection to the symlink/copy idea as well? Second, I don't like the idea of doing things that surprise users. That will confuse people. It also causes recursiveness so the idea is lame unless we also trap the recursive nature to one instance. I don't think it is that confusing but perhaps --with-config-dir=/path/to/config files might be nice and configure would execute the config.guess and config.sub in that directory or error if the files do not exist or are unreadable. -- Earnie -- https://sites.google.com/site/earnieboyd ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 08:21:09AM -0400, Earnie Boyd wrote: First, this does not solve the problem because it requires that every package get a new version of config.guess. We're trying to overcome having to modify every package. So that's your objection to the symlink/copy idea as well? No .. I don't have any objection to that. It's a rather unobtrusive way and will work with every package, regardless of vintage. Ben signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 05/21/2013 04:59 AM, Earnie Boyd wrote: Maybe have a common directory of /usr/[local/]share/autoconf/auxdir and teach autoconf to look there if it doesn't find config.guess/config.sub in the project directory and copy them when copy is specified? I dislike the environment variable idea. Too fragile, someone forgets it is set and then has trouble because the config.guess/config.sub he's trying to use isn't being used. I know you mean for the variable to be set at autoreconf/configure usage but there are always idiots who install it into their .profile files and forget they did that. Sorry, but this is the autoconf maintainer speaking: I much prefer the environment variable approach. It is the same as we do for other tools, such as $CC or $GREP. Users already have to be aware of environment variables they have set; furthermore, we can mark such variables as precious so that config.log records what was used. Quit trying to overengineer a path search - all I am willing to commit into autoconf is an environment variable override. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 05/21/2013 05:56 AM, Earnie Boyd wrote: On Tue, May 21, 2013 at 7:36 AM, Ben Elliston wrote: Yes, but that requires re-running autoconf. I think we're trying to avoid that because if configure.in is old, you may have a lot of work to do to get autoreconf to work. So in that case, a change to the start of config.guess and config.sub something similar to the following might be best? ~ if [[ -f /usr/local/share/config/config.guess ]] then . /usr/local/share/config/config.guess exit fi if [[ -f /usr/share/config/config.guess ]] then . /usr/share/config/config.guess exit fi That would be fine with me, if you can get the upstream config project to agree to it, since it would not require autoconf to do anything more than recognize an environment variable. But are these scripts really source-able, or should you be directly executing them? And does it have proper avoidance of infinite loop if such a version of config.guess is installed into /usr/local/share/config/config.guess? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tuesday 2013-05-21 07:33, Pavel Raiskup wrote: Works for me. But we [distros] do want to mandate autoreconf anyway in the general case: it is the *only* way to keep upstream honest about the much hated build system not bitrotting until it decides to blow up right when we need it for a security update. I know. But there is a lot of tarballs not able to be easily autoreconf-ed (more than 10 years old) and not having upstream.. and it needs a lot of changes downstream before autoreconf successes.. (and you need to have a quite good knowledge about auto-toolset). If upstream is dead, the distros should perhaps reevaluate whether to drop the package or de facto become upstream by a process of adoption. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
Works for me. But we [distros] do want to mandate autoreconf anyway in the
general case: it is the *only* way to keep upstream honest about the much
hated build system not bitrotting until it decides to blow up right when we
need it for a security update.
I know. But there is a lot of tarballs not able to be easily
autoreconf-ed (more than 10 years old) and not having upstream.. and it
needs a lot of changes downstream before autoreconf successes.. (and you
need to have a quite good knowledge about auto-toolset).
If upstream is dead, the distros should perhaps reevaluate whether to
drop the package or de facto become upstream by a process of adoption.
Yes. But if the problem is as easy as outdated config.{guess,sub}, simply
setting the CONFIG_{GUESS,SUB} variable is far more suitable. Sometimes
distros are deploying compat packages having outdated sources.
What about this? Ben (and others), would you consider something similar
like this one? Without PATH traversal it could be very trivial:
diff --git a/config.sub b/config.sub
index 8b612ab..daac889 100755
--- a/config.sub
+++ b/config.sub
@@ -50,6 +50,12 @@ timestamp='2013-04-24'
# CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
# It is wrong to echo any other type of specification.
+if test -n $CONFIG_SUB; then
+# clean CONFIG_SUB variable!
+CONFIG_SUB= $CONFIG_SUB $1
+exit
+fi
+
me=`echo $0 | sed -e 's,.*/,,'`
usage=\
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
I suggested a simple, low impact way of updating the files, particularly for people wanting to build a large number of packages (eg, for a distro). Can anyone tell me why this approach is not satisfactory? Ben signature.asc Description: Digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 7:21 PM, Ben Elliston wrote: I suggested a simple, low impact way of updating the files, particularly for people wanting to build a large number of packages (eg, for a distro). Can anyone tell me why this approach is not satisfactory? It's what I've done for years. Does it get rid of the problem? I don't think so but for legacy code that is no longer being maintained, either you maintain it, or the problem exists into infinity with a hard stop when someone does maintain it. I think the battle is trying to overcome continuing the legacy method of needing to replace config.guess/config.sub within a package and allow a common (or configurable) location be used as new development takes place. Your symlink/copy method doesn't overcome that legacy method so it would not be a satisfactory solution since that solution continues the legacy method. However, your solution does help those with packages that currently use that legacy method. -- Earnie -- https://sites.google.com/site/earnieboyd ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Thursday 16 May 2013 15:28:39 Warren Young wrote: On 5/15/2013 14:27, Mike Frysinger wrote: On Wednesday 15 May 2013 15:25:31 Warren Young wrote: we've got pretty good coverage for anything passably relevant (and then some). So, because Gentoo has N text editors in the repo, the N+1th text editor must port to Gentoo without problems? You're committing a logical fallacy here, hasty generalization. All things in class A have property B, hence all things have property B. how about you focus on the things i've actually said rather than making up things and attributing them to me. i've chopped a couple of sections of your e-mail as they were largely redundant. You propose changing the way autoconf works based on a sampling of projects using it. A large sampling to be sure, but probably not anywhere near a majority of those using autotools. so you're proposing we never make a change because we haven't located and tested every single project ever conceived w/autotools ? obviously that is literally impossible and any such proposal is the exact antithesis to progress. in order to make a change, you need to weigh real world impact which means you need samples. the samples stated by the various distros (arguably the largest builders of source code) are significantly strong data points to indicate that this is a dead feature. I *still* run across autoconfiscated packages using configure.in, despite years of warnings from Autoconf. autoconf has never warned about it afaik. automake-1.12 was the first release to complain, and that was released 24 Apr 2012 (just barely a year). which means in order to see these warnings, people need to be running a recent distro (checking ubuntu real quick shows it still doesn't have it), as well as be using automake (some projects like to use just autoconf). which means there are a good number of developers who aren't seeing the warning even today. so i don't know what you're referring to here. When autoconf stops recognizing configure.in, I fully expect to hear wails, Why did you break this? so what ? they'll rename things and move on. This idea isn't entirely bad. It's attempting to fix a real problem. There's another problem pressing up against it from the other direction, though: an implicit promise built up over decades of the Autotools' existence that certain behaviors are allowed. When the rules change without warning, people get upset. a mere implementation detail And no, this thread doesn't count as fair warning. i don't think anyone has considered announced on mailing list fair warning for autotool packages. that is what NEWS is for as well as generated warnings when you run them. [1] When I characterize Gentoo as anti-commercial, I simply mean that the distro proper does not contain paid commercial software, to my knowledge. we have plenty of ebuilds in the main tree that install proprietary binary- only packages. as in, you need to buy/license the package before you even get a chance to install it. i'm also aware of companies who use Gentoo to build/maintain their internal proprietary packages which either never get released externally, or only done so as binary packages. so i guess your characterization is inaccurate. The closed, secretive mindset behind such software must result in some differences in software development practice from that used by open source, so you cannot extend your knowledge from open source software to predict how closed source software development works. i've worked on closed sourced projects (both internal-only and released to the world) at various companies in the past, as well as supported other companies writing closed source software. there's no generalization you can make to cover them all, although stupidity is frequently a common theme. -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2013-05-20 at 07:40 +0200, Pavel Raiskup wrote:
Yes, it was mentioned multiple times in this thread already and it was
always forgotten. Please consider this approach.
The patches I've posted include environment variables too.
One thing was not mentioned here - if there was a CONFIG_GUESS/CONFIG_SUB
environment variables, what would be the consequences of having it solved
directly in config.{guess,sub} files?
Both versions of the patch I posted for autoconf used these variables.
I mean, if there was defined CONFIG_GUESS environment variable, the
config.guess could try to call 'config.guess' file somewhere in $PATH?
Modifying the config.guess/sub files to call other versions of
themselves was rejected by the maintainers a long time ago. My first
patch was for config.guess/sub to search the system for the latest
version and run it. That was rejected. The current approach is to change
the code that runs config.guess/sub so that it finds the latest
available version and runs it, with the possibility to override, mainly
for folks developing new ports.
pros: we are able to easily patch also old packages (no-need to
autoreconfigure)
There would still be a long bootstrap period where old tarballs would
not have any way of running a modern config.sub/guess other than copying
them in from the system versions.
This is a fundamental problem of autotools, it comes from the days when
the system was probably a proprietary, old and buggy UNIX but we now
live in the days of fairly good and up-to-date Linux distributions where
we build software that wasn't necessarily autoreconfed with the latest
version of autotools. We need it to move to a hybrid model; use the
system version of everything unless it is old or missing.
--
bye,
pabs
http://bonedaddy.net/pabs3/
signature.asc
Description: This is a digitally signed message part
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
pros: we are able to easily patch also old packages (no-need to autoreconfigure) There would still be a long bootstrap period where old tarballs would not have any way of running a modern config.sub/guess other than copying them in from the system versions. I meant that you are able to patch the very small part of config.guess/config.sub with checking for environmental variables and thats all - you don't have to touch this package in future. The patched config.sub is able to call system's one. No need to bootstrap. Modifying the config.guess/sub files to call other versions of themselves was rejected by the maintainers a long time ago. Was there considered environmental variable approach? Pavel ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2013-05-20 at 08:43 +0200, Pavel Raiskup wrote: I meant that you are able to patch the very small part of config.guess/config.sub with checking for environmental variables and thats all - you don't have to touch this package in future. The patched config.sub is able to call system's one. No need to bootstrap. There are thousands of copies of config.guess/sub (or configure scripts) out there (in tarballs) with no support for this at all. Once it is added to config.guess/sub in git (or autoconf) then it will take many years before the majority of copies of config.guess/sub (or configure scripts) have support for this. This is what I mean by bootstrap phase. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 05/18/2013 05:45 AM, Paul Wise wrote: On Fri, 2013-05-17 at 16:05 -0300, Henrique de Moraes Holschuh wrote: Yes. It would have been really useful if autofoo used whatever is in /usr/share/misc, unless there is a config.sub.override or config.guess.override file in the source directory (or even better, something pointed to by environment variables), and deprecate source-directory config.guess and config.sub. My original patch didn't allow overrides, here is an updated one. I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB environment variable, rather than baking in a PATH search. This topic has come up in the past, where I made the same request back then. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2013-05-20 at 08:37 -0600, Eric Blake wrote: I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB environment variable, rather than baking in a PATH search. This topic has come up in the past, where I made the same request back then. The patch does both and both are needed AFAICT. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 05/20/2013 09:01 AM, Paul Wise wrote: On Mon, 2013-05-20 at 08:37 -0600, Eric Blake wrote: I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB environment variable, rather than baking in a PATH search. This topic has come up in the past, where I made the same request back then. The patch does both and both are needed AFAICT. I disagree. Env-var override should be sufficient, without needing any PATH probing. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2013-05-20 at 09:11 -0600, Eric Blake wrote: On 05/20/2013 09:01 AM, Paul Wise wrote: On Mon, 2013-05-20 at 08:37 -0600, Eric Blake wrote: I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB environment variable, rather than baking in a PATH search. This topic has come up in the past, where I made the same request back then. The patch does both and both are needed AFAICT. I disagree. Env-var override should be sufficient, without needing any PATH probing. FWIW I agree with Eric. Having behind-the-scenes path probing for local overrides is, IMO, asking for a lot of trouble. It's far to easy to drop a file on your system and forget about it it, leading to much confusion and frustration a few months/years later. Also consider the support burden... I just don't see the need for it. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
+++ Eric Blake [2013-05-20 09:11 -0600]: On 05/20/2013 09:01 AM, Paul Wise wrote: On Mon, 2013-05-20 at 08:37 -0600, Eric Blake wrote: I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB environment variable, rather than baking in a PATH search. This topic has come up in the past, where I made the same request back then. The patch does both and both are needed AFAICT. I disagree. Env-var override should be sufficient, without needing any PATH probing. The problem with this in the context of distro buildds was explained in this sub-part of the thread from Oct last year: http://article.gmane.org/gmane.comp.sysutils.autoconf.general/14756 ENV VARS are carefully filtered out of buildd environments in order to get clean builds. We really want a mechanism where the distro default build just looks in the right (system) place, unless you ask for something different. Now it probably is possible to get this ENV VAR set in buildd environments, but what if the cmake, maven, ant, scons and $everybody else also insist on the same mechanism for default builds to work properly? That's a lot of ENV VARS - it doesn't scale well. And if someone does a local build outside the buildd environment now they have to remember to set these variables too, otherwise suddenly stuff that built on the buildds doesn't build for them. ENV VARS are very useful for all sorts of things, but they are problematic for distro build defaults, so there is a good reason for the path walk. Now we could patch autoconf in Debian (and other distros patch it too) to deal with this, but the whole point of this excercise is to fix this upstream so that over time the problem will just fade into history. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 05/20/2013 09:37 AM, Wookey wrote: +++ Eric Blake [2013-05-20 09:11 -0600]: On 05/20/2013 09:01 AM, Paul Wise wrote: On Mon, 2013-05-20 at 08:37 -0600, Eric Blake wrote: I would MUCH rather see us honor a CONFIG_GUESS and CONFIG_SUB environment variable, rather than baking in a PATH search. This topic has come up in the past, where I made the same request back then. The patch does both and both are needed AFAICT. I disagree. Env-var override should be sufficient, without needing any PATH probing. The problem with this in the context of distro buildds was explained in this sub-part of the thread from Oct last year: http://article.gmane.org/gmane.comp.sysutils.autoconf.general/14756 ENV VARS are carefully filtered out of buildd environments in order to get clean builds. We really want a mechanism where the distro default build just looks in the right (system) place, unless you ask for something different. The distro default build system should SET such an env-var. Problem solved, no path search needed. Clean builds are a product of using the same environment, and that can include SETTING useful variables, rather than scrubbing them. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 20 May 2013, Pavel Raiskup wrote:
+cc config-patc...@gnu.org, Ben Elliston b...@air.net.au
IME, it is much better when any override mechanism make use of
environment variables.
Yes, it was mentioned multiple times in this thread already and it was
always forgotten. Please consider this approach.
One thing was not mentioned here - if there was a CONFIG_GUESS/CONFIG_SUB
environment variables, what would be the consequences of having it solved
directly in config.{guess,sub} files?
I mean, if there was defined CONFIG_GUESS environment variable, the
config.guess could try to call 'config.guess' file somewhere in $PATH?
pros: we are able to easily patch also old packages (no-need to
autoreconfigure)
Works for me. But we [distros] do want to mandate autoreconf anyway in the
general case: it is the *only* way to keep upstream honest about the much
hated build system not bitrotting until it decides to blow up right when we
need it for a security update.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
Works for me. But we [distros] do want to mandate autoreconf anyway in the general case: it is the *only* way to keep upstream honest about the much hated build system not bitrotting until it decides to blow up right when we need it for a security update. I know. But there is a lot of tarballs not able to be easily autoreconf-ed (more than 10 years old) and not having upstream.. and it needs a lot of changes downstream before autoreconf successes.. (and you need to have a quite good knowledge about auto-toolset). I'm glad to see that problem is approaching even solution requiring autoconf .. not forcing anybody, just wanted to make sure that this was also considered (and also that config-patches mailing list is also CC'd). ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
+cc config-patc...@gnu.org, Ben Elliston b...@air.net.au
IME, it is much better when any override mechanism make use of
environment variables.
Yes, it was mentioned multiple times in this thread already and it was
always forgotten. Please consider this approach.
One thing was not mentioned here - if there was a CONFIG_GUESS/CONFIG_SUB
environment variables, what would be the consequences of having it solved
directly in config.{guess,sub} files?
I mean, if there was defined CONFIG_GUESS environment variable, the
config.guess could try to call 'config.guess' file somewhere in $PATH?
pros: we are able to easily patch also old packages (no-need to
autoreconfigure)
Pavel
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Fri, 2013-05-17 at 16:05 -0300, Henrique de Moraes Holschuh wrote: Yes. It would have been really useful if autofoo used whatever is in /usr/share/misc, unless there is a config.sub.override or config.guess.override file in the source directory (or even better, something pointed to by environment variables), and deprecate source-directory config.guess and config.sub. My original patch didn't allow overrides, here is an updated one. -- bye, pabs http://bonedaddy.net/pabs3/ From 17afa8e123997e21e55755cfaaae07b5f84de690 Mon Sep 17 00:00:00 2001 From: Paul Wise pa...@bonedaddy.net Date: Tue, 9 Oct 2012 11:06:37 +0800 Subject: [PATCH] Check a number of paths for newer config.guess/config.sub, run the latest. This helps people who are bootstrapping new systems from existing software that uses GNU autotools, config.guess and config.sub. This is very useful for distributions like Debian that add new architectures and then have to update config.sub and config.guess in every single package that uses automake or have to workaround the problem by adding code to each package to copy in the latest versions of these scripts from another package containing the latest version of the scripts (autotools-dev in Debian). Allow software authors and distro porters to override the latest version. --- lib/autoconf/general.m4 | 72 ++--- 1 file changed, 56 insertions(+), 16 deletions(-) diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4 index 70b0168..f746b73 100644 --- a/lib/autoconf/general.m4 +++ b/lib/autoconf/general.m4 @@ -1680,6 +1680,51 @@ AC_DEFUN([AC_CONFIG_AUX_DIR], AC_DEFUN([AC_CONFIG_AUX_DIR_DEFAULT], [AC_CONFIG_AUX_DIRS($srcdir $srcdir/.. $srcdir/../..)]) +# AC_CONFIG_AUX_DIR +# - +# Internal subroutine. +# Find the latest version of config.guess and config.sub that is +# available on the system to prevent issues with bootstrapping. +# Allows explicitly overriding the latest one where needed. +AC_DEFUN([AC_CONFIG_AUX_DIR, +[ +for path in \ + $AUTOCONF_AUX_DIR \ + $HOME/.config/autotools \ + $2 \ + ; do +if test -x $path/config.$1.override ; then + ac_config_$1=$path/config.$1.override +fi +done +if test -z $ac_config_$1 ; then + cur_v=0 + for path in \ +$AUTOCONF_AUX_DIR \ +$2 \ +$HOME/.config/autotools \ +/usr/local/share/automake-* \ +/usr/local/share/automake \ +/usr/local/share/libtool/config \ +/usr/share/misc \ +/usr/share/gnuconfig \ +/usr/share/automake-* \ +/usr/share/automake \ +/usr/share/libtool/config \ +$[CONFIG_]m4_toupper([$1]) \ +; do + if test -x $path/config.$1 ; then +v=`$SHELL $path/config.$1 --time-stamp | sed s/-//g` +if test $v -gt $cur_v ; then + cur_v=$v + latest=$path +fi + fi + done + ac_config_$1=$latest/config.$1 +fi +])# AC_CONFIG_AUX_DIR + # AC_CONFIG_AUX_DIRS(DIR ...) # --- @@ -1708,13 +1753,8 @@ if test -z $ac_aux_dir; then AC_MSG_ERROR([cannot find install-sh, install.sh, or shtool in $1]) fi -# These three variables are undocumented and unsupported, -# and are intended to be withdrawn in a future Autoconf release. -# They can cause serious problems if a builder's source tree is in a directory -# whose full name contains unusual characters. -ac_config_guess=$SHELL $ac_aux_dir/config.guess # Please don't use this var. -ac_config_sub=$SHELL $ac_aux_dir/config.sub # Please don't use this var. -ac_configure=$SHELL $ac_aux_dir/configure # Please don't use this var. +AC_CONFIG_AUX_DIR([guess],[$1]) +AC_CONFIG_AUX_DIR([sub],[$1]) AC_PROVIDE([AC_CONFIG_AUX_DIR_DEFAULT])dnl ])# AC_CONFIG_AUX_DIRS @@ -1832,17 +1872,17 @@ m4_divert_once([HELP_CANON], System types: --build=BUILD configure for building on BUILD [guessed]]])dnl # Make sure we can run config.sub. -$SHELL $ac_aux_dir/config.sub sun4 /dev/null 21 || - AC_MSG_ERROR([cannot run $SHELL $ac_aux_dir/config.sub]) +$SHELL $ac_config_sub sun4 /dev/null 21 || + AC_MSG_ERROR([cannot run $SHELL $ac_config_sub]) AC_CACHE_CHECK([build system type], [ac_cv_build], [ac_build_alias=$build_alias test x$ac_build_alias = x - ac_build_alias=`$SHELL $ac_aux_dir/config.guess` + ac_build_alias=`$SHELL $ac_config_guess` test x$ac_build_alias = x AC_MSG_ERROR([cannot guess build type; you must specify one]) -ac_cv_build=`$SHELL $ac_aux_dir/config.sub $ac_build_alias` || - AC_MSG_ERROR([$SHELL $ac_aux_dir/config.sub $ac_build_alias failed]) +ac_cv_build=`$SHELL $ac_config_sub $ac_build_alias` || + AC_MSG_ERROR([$SHELL $ac_config_sub $ac_build_alias failed]) ]) _AC_CANONICAL_SPLIT(build) ])# AC_CANONICAL_BUILD @@ -1858,8 +1898,8 @@ AC_CACHE_CHECK([host system type], [ac_cv_host], [if test x$host_alias = x; then ac_cv_host=$ac_cv_build else - ac_cv_host=`$SHELL $ac_aux_dir/config.sub $host_alias` || -AC_MSG_ERROR([$SHELL $ac_aux_dir/config.sub $host_alias
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Sat, 18 May 2013, Paul Wise wrote:
On Fri, 2013-05-17 at 16:05 -0300, Henrique de Moraes Holschuh wrote:
Yes. It would have been really useful if autofoo used whatever is in
/usr/share/misc, unless there is a config.sub.override or
config.guess.override file in the source directory (or even better,
something pointed to by environment variables), and deprecate
source-directory config.guess and config.sub.
My original patch didn't allow overrides, here is an updated one.
IME, it is much better when any override mechanism make use of environment
variables. These are very easy to set per-build, per-user and system-wide,
unlike system-wide files and even per-project files.
It would be enough for the environment variables, when present, set the name
of the override files, and default to local config.{sub,guess}.override or
whatever when the variables are not set.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Thu, 16 May 2013, Paul Wise wrote: On Wed, 2013-05-15 at 16:30 +0200, Thomas Petazzoni wrote: On Tue, 14 May 2013 23:53:44 -0400, Mike Frysinger wrote: yes, Gentoo fixed this for every package in our tree like 9 years ago FWIW, we do the same thing in Buildroot Yes, it is a very common hack in all of the distros. It would be nice if that wasn't necessary in the first place though. Yes. It would have been really useful if autofoo used whatever is in /usr/share/misc, unless there is a config.sub.override or config.guess.override file in the source directory (or even better, something pointed to by environment variables), and deprecate source-directory config.guess and config.sub. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 5/17/2013 13:05, Henrique de Moraes Holschuh wrote:
It would have been really useful if autofoo used whatever is in
/usr/share/misc, unless there is a config.sub.override or
config.guess.override file
You're starting from an assumption that autotools are installed on all
systems where you would want to build an autoconfiscated package.
For example, on Cygwin and FreeBSD, a C compiler is optional, and
installing it doesn't drag in the autotools.
All you're supposed to need to build an autoconfiscated package are
sh(1), make(1), and the compiler for whatever language the package's
source code is in.
I think you have the seed of a good idea here, though.
What if configure behaves just like it currently does unless it sees
that config.{guess,sub}[.override] aren't present at all? It can then
go looking for default versions in the usual system locations.
OS package creation tools could offer a per-package flag in the
package's configuration (.spec, .ebuild, .cygport, debian/...) that
tells it it is safe to remove shipped config.{guess,sub} files from the
tarball when building the source package, and that it should autoreconf
the package to get a configure script and Makefile.in that's aware of
this new behavior. The idea here is that binary package building
workstations *can* be assumed to have autotools installed.
It would also be useful if generated configure scripts supported a
--no-local-guess flag which forces it to look for system versions even
if it finds them in the same directory as the configure script. That
way a tarball can *ship* with config.{guess,sub}, but when a package
maintainer knows the system versions are going to work better, it can
pass that flag without autoreconf'ing the package.
You might think that unnecessarily fiddly, but it's based on an
experience of mine just last month. I was trying to build something
that shipped with outdated config.{guess,sub} files, but I couldn't
autoreconf it because its configure.ac file was *also* written in a
style so obsolescent that autoconf refused to cope with it. The package
creation tool helpfully tried overwriting config.{guess,sub} but it
did so with versions that were still too old, so even if I overwrote
them ahead of time, it clobbered my fixes.
That --no-local-guess flag would have saved me some aggravation.
Yes, I realize such behavior won't save me for another 3+ years, if I
have my way. I'd rather have these features painlessly in the future
than break a hundred thousand tarballs so I can have these features now.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 5/15/2013 14:27, Mike Frysinger wrote: On Wednesday 15 May 2013 15:25:31 Warren Young wrote: we've got pretty good coverage for anything passably relevant (and then some). So, because Gentoo has N text editors in the repo, the N+1th text editor must port to Gentoo without problems? You're committing a logical fallacy here, hasty generalization. All things in class A have property B, hence all things have property B. The packages in Gentoo are ipso facto packages that *can* port to Gentoo. You can't infer from that that all packages port to Gentoo without requiring adjustment. I wouldn't be surprised if there were an iceberg effect here: it could well be that ~90% of all source trees using the autotools aren't even publicly visible, much less incorporated into the major Linux distros. then they're irrelevant to this sub thread. Why? You propose changing the way autoconf works based on a sampling of projects using it. A large sampling to be sure, but probably not anywhere near a majority of those using autotools. You *think* you know how your change will affect all those projects you don't get to see, but you do not actually know, because you're working from a biased sample. (Biased because it's an inherently anti-closed source, anti-commercial[1] sample.) This seems like it might be a relevant consideration to me. when things break w/Gentoo, our devs/users tend to file bugs. Fallen tree fallacy. When the entry in the bug tracker (in a forest of bug trackers) is not filled out, does the bug exist? if Gentoo blowing away your rinky dinky config.sub hack breaks your project, then take it as a sign that You're Doing It Wrong :). Quite possibly. Truly, I agree. But now go ask Stefano Lattarini how well-intentioned changes, made to the behavior of the autotools without a gradual phase-in period over years affect real world user reaction to those changes. I *still* run across autoconfiscated packages using configure.in, despite years of warnings from Autoconf. I've even sent off bug reports to those packages about it, and the obsolete name remains in their source repo to this day. When autoconf stops recognizing configure.in, I fully expect to hear wails, Why did you break this? This idea isn't entirely bad. It's attempting to fix a real problem. There's another problem pressing up against it from the other direction, though: an implicit promise built up over decades of the Autotools' existence that certain behaviors are allowed. When the rules change without warning, people get upset. And no, this thread doesn't count as fair warning. The vast majority of autotools users don't read this list, and likely couldn't find this thread in Google if they had a problem that this thread explained. What those users see is that their OS of choice upgrades the autotools, and suddenly the rules have changed. - [1] When I characterize Gentoo as anti-commercial, I simply mean that the distro proper does not contain paid commercial software, to my knowledge. The closed, secretive mindset behind such software must result in some differences in software development practice from that used by open source, so you cannot extend your knowledge from open source software to predict how closed source software development works. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 05/15/2013 05:53 AM, Mike Frysinger wrote: On Monday 08 October 2012 08:46:57 Paul Wise wrote: So, Debian is in the process of bringing up our upcoming arm64 port. Unfortunately we are also coming across lots of packages with rather outdated config.guess and config.sub files (see links below). We could patch every single package that contains config.guess and config.sub but that would be a lot of effort that doesn't scale. We could also patch our build tools but the problem would still exist for other distros. yes, Gentoo fixed this for every package in our tree like 9 years ago (we added a common function like 11 years ago that ebuilds could call manually, but we found that didn't scale). when you run a standard autoconf script, we automatically search for files named config.sub and config.guess and replace them with the up-to-date host copy. no checking or anything :). in hindsight, that seems like a bad idea, but in practice, i think we have yet to find a package that this doesn't actually work. Well, I can't imagine a case affecting config.guess, but constructing cases affecting config.sub is pretty simple. Classical use-case is developing on cross-built packages, which require a new host/target-tuple and therefore ship a customized/modified config.sub. Those cases are rare in publicly available/released packages, but they are not uncommon in the toolchain/OS developer's community. Think about working on cfin-MikeOS toolchain in binutils/gcc/gdb or adding support for it to other auto*tools-based package ;) At least for RTEMS, we had once carried such a customized config.sub for a short period time. Ralf ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
Hello, On Tue, 14 May 2013 23:53:44 -0400, Mike Frysinger wrote: yes, Gentoo fixed this for every package in our tree like 9 years ago (we added a common function like 11 years ago that ebuilds could call manually, but we found that didn't scale). when you run a standard autoconf script, we automatically search for files named config.sub and config.guess and replace them with the up-to-date host copy. no checking or anything :). in hindsight, that seems like a bad idea, but in practice, i think we have yet to find a package that this doesn't actually work. FWIW, we do the same thing in Buildroot (a tool that builds embedded Linux systems from source, through cross-compilation). Never had any problem doing so. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Wednesday 15 May 2013 09:54:08 Ralf Corsepius wrote: On 05/15/2013 05:53 AM, Mike Frysinger wrote: On Monday 08 October 2012 08:46:57 Paul Wise wrote: So, Debian is in the process of bringing up our upcoming arm64 port. Unfortunately we are also coming across lots of packages with rather outdated config.guess and config.sub files (see links below). We could patch every single package that contains config.guess and config.sub but that would be a lot of effort that doesn't scale. We could also patch our build tools but the problem would still exist for other distros. yes, Gentoo fixed this for every package in our tree like 9 years ago (we added a common function like 11 years ago that ebuilds could call manually, but we found that didn't scale). when you run a standard autoconf script, we automatically search for files named config.sub and config.guess and replace them with the up-to-date host copy. no checking or anything :). in hindsight, that seems like a bad idea, but in practice, i think we have yet to find a package that this doesn't actually work. Well, I can't imagine a case affecting config.guess, but constructing cases affecting config.sub is pretty simple. Classical use-case is developing on cross-built packages, which require a new host/target-tuple and therefore ship a customized/modified config.sub. i take the stance that if you haven't merged your code into the GNU config project, then you deserve to break. or at least, you're too bleeding edge to be merged into mainline Gentoo (which, honestly, is saying something). i keep the snapshots in Gentoo up to date every few months, or someone asks for it sooner (as they just got a change merged), so there's very little to no delay syncing there. and counter point: if someone wants to use e.g. Gentoo to develop things early, they can also tweak the host system's gnuconfig package and then *all* the Gentoo ebuilds now build correctly for your target :). -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 05/15/2013 06:13 PM, Mike Frysinger wrote: On Wednesday 15 May 2013 09:54:08 Ralf Corsepius wrote: On 05/15/2013 05:53 AM, Mike Frysinger wrote: On Monday 08 October 2012 08:46:57 Paul Wise wrote: So, Debian is in the process of bringing up our upcoming arm64 port. Unfortunately we are also coming across lots of packages with rather outdated config.guess and config.sub files (see links below). We could patch every single package that contains config.guess and config.sub but that would be a lot of effort that doesn't scale. We could also patch our build tools but the problem would still exist for other distros. yes, Gentoo fixed this for every package in our tree like 9 years ago (we added a common function like 11 years ago that ebuilds could call manually, but we found that didn't scale). when you run a standard autoconf script, we automatically search for files named config.sub and config.guess and replace them with the up-to-date host copy. no checking or anything :). in hindsight, that seems like a bad idea, but in practice, i think we have yet to find a package that this doesn't actually work. Well, I can't imagine a case affecting config.guess, but constructing cases affecting config.sub is pretty simple. Classical use-case is developing on cross-built packages, which require a new host/target-tuple and therefore ship a customized/modified config.sub. i take the stance that if you haven't merged your code into the GNU config project, then you deserve to break. Well, config.sub has allways been amongst those files the autotools supposed not to be generated. That said, if you replace them by brute-force, you are breaking the UI of the autotools - Read: an utterly bad idea. RH/Fedora has done this for a very long time and has given up doing so for several years, and now is relying on packagers explicitly replacing them (autoreconf -f rsp. by patching). A better approach would be to only replace them, if they you are sure, they are unmodified. or at least, you're too bleeding edge to be merged into mainline Gentoo (which, honestly, is saying something). comments non-disclosed/ Ralf ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Wednesday 15 May 2013 12:26:46 Ralf Corsepius wrote: On 05/15/2013 06:13 PM, Mike Frysinger wrote: On Wednesday 15 May 2013 09:54:08 Ralf Corsepius wrote: On 05/15/2013 05:53 AM, Mike Frysinger wrote: On Monday 08 October 2012 08:46:57 Paul Wise wrote: So, Debian is in the process of bringing up our upcoming arm64 port. Unfortunately we are also coming across lots of packages with rather outdated config.guess and config.sub files (see links below). We could patch every single package that contains config.guess and config.sub but that would be a lot of effort that doesn't scale. We could also patch our build tools but the problem would still exist for other distros. yes, Gentoo fixed this for every package in our tree like 9 years ago (we added a common function like 11 years ago that ebuilds could call manually, but we found that didn't scale). when you run a standard autoconf script, we automatically search for files named config.sub and config.guess and replace them with the up-to-date host copy. no checking or anything :). in hindsight, that seems like a bad idea, but in practice, i think we have yet to find a package that this doesn't actually work. Well, I can't imagine a case affecting config.guess, but constructing cases affecting config.sub is pretty simple. Classical use-case is developing on cross-built packages, which require a new host/target-tuple and therefore ship a customized/modified config.sub. i take the stance that if you haven't merged your code into the GNU config project, then you deserve to break. Well, config.sub has allways been amongst those files the autotools supposed not to be generated. That said, if you replace them by brute-force, you are breaking the UI of the autotools - Read: an utterly bad idea. RH/Fedora has done this for a very long time and has given up doing so for several years, and now is relying on packagers explicitly replacing them (autoreconf -f rsp. by patching). i understand the point you're making. however, ~10 years of building from source in Gentoo and doing this for every single build has shown that in practice, it's irrelevant. we've found exactly one package where this made a slight difference (gmp), and even then it was a matter of selecting optional optimizations that we can control via other routes. -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
Thomas Petazzoni thomas.petazz...@free-electrons.com writes: On Tue, 14 May 2013 23:53:44 -0400, Mike Frysinger wrote: yes, Gentoo fixed this for every package in our tree like 9 years ago (we added a common function like 11 years ago that ebuilds could call manually, but we found that didn't scale). when you run a standard autoconf script, we automatically search for files named config.sub and config.guess and replace them with the up-to-date host copy. no checking or anything :). in hindsight, that seems like a bad idea, but in practice, i think we have yet to find a package that this doesn't actually work. FWIW, we do the same thing in Buildroot (a tool that builds embedded Linux systems from source, through cross-compilation). Never had any problem doing so. Debian is moving in that direction as well. We have two different package helper tools that do this in different ways. As always with Debian, though, we're not very centralized about practices, so it takes a while to get this deployed consistently across the whole archive. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 5/15/2013 11:20, Mike Frysinger wrote: i understand the point you're making. however, ~10 years of building from source in Gentoo and doing this for every single build has shown that in practice, it's irrelevant. It's irrelevant *for* *Gentoo*. Not all autoconfiscated source trees are in Gentoo. I wouldn't be surprised if there were an iceberg effect here: it could well be that ~90% of all source trees using the autotools aren't even publicly visible, much less incorporated into the major Linux distros. There's some self-selection bias going on here, too. Software that fails to build in the Gentoo build system obviously won't get adopted into Gentoo, if no one bothers to try and fix the breakage. For what it's worth, I'm not entirely against your position. I do a bit of packaging work for Cygwin, and we've got the same core problem over there, too, particularly with the nascent Cygwin 64 effort. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Wednesday 15 May 2013 15:25:31 Warren Young wrote: On 5/15/2013 11:20, Mike Frysinger wrote: i understand the point you're making. however, ~10 years of building from source in Gentoo and doing this for every single build has shown that in practice, it's irrelevant. It's irrelevant *for* *Gentoo*. Not all autoconfiscated source trees are in Gentoo. ... which is what this sub thread was focusing on, with the only slightly bigger picture being distro packaging behavior. no, not *all* autotool based packages are in Gentoo, but we've got pretty good coverage for anything passably relevant (and then some). I wouldn't be surprised if there were an iceberg effect here: it could well be that ~90% of all source trees using the autotools aren't even publicly visible, much less incorporated into the major Linux distros. then they're irrelevant to this sub thread. There's some self-selection bias going on here, too. Software that fails to build in the Gentoo build system obviously won't get adopted into Gentoo, if no one bothers to try and fix the breakage. obviously that's possible, but i'm fairly certain it's unlikely. when things break w/Gentoo, our devs/users tend to file bugs. even then, writing your own config.sub is not something to be taken lightly. the amount of blood/sweat/tears that have gone into maintaining that database dwarfs whatever tiny project random person is working on. and even even then, the number of people who even understand htf autotools work let alone a tiny internal nuance like config.sub is fairly (if not extremely) esoteric. if Gentoo blowing away your rinky dinky config.sub hack breaks your project, then take it as a sign that You're Doing It Wrong :). -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
Mike Frysinger vap...@gentoo.org writes: if Gentoo blowing away your rinky dinky config.sub hack breaks your project, then take it as a sign that You're Doing It Wrong :). I think this may be one of those historical momentum things. As INN maintainer, I used to carry local patches to config.guess and config.sub to add support for platforms on which my users were trying to build INN that weren't supported by the current config.guess and config.sub scripts, usually because the patches had been submitted but they were very slow to release a new version. This problem went away completely some time back, with a new and far faster and more responsive process for maintaining those scripts, and now I just use the most recent released versions for all packages. Some projects may still be carrying unnecessary hacks because they started carrying them back in those days and have never gone back and revisited. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
+++ Thomas Petazzoni [2013-05-15 16:30 +0200]: Hello, On Tue, 14 May 2013 23:53:44 -0400, Mike Frysinger wrote: yes, Gentoo fixed this for every package in our tree like 9 years ago (we added a common function like 11 years ago that ebuilds could call manually, but we found that didn't scale). when you run a standard autoconf script, we automatically search for files named config.sub and config.guess and replace them with the up-to-date host copy. no checking or anything :). in hindsight, that seems like a bad idea, but in practice, i think we have yet to find a package that this doesn't actually work. FWIW, we do the same thing in Buildroot (a tool that builds embedded Linux systems from source, through cross-compilation). Never had any problem doing so. Same story in OpenEmbedded. Given the widespread positive experience with this process, at least in Linux distros, can those who think that defaulting to using 'current' versions is a bad idea produce any examples of genuine problems large enough to counter the fairly major issue of updating hundreds of these files for new architectures. Perhaps there are non-linux arches where lots of things would break? There have been some theoretical or obscure issues brought up so far in this thread, and some history, but I haven't seen much that looks like a good enough reason not to default to use current unless configured not to (which anyone shipping a 'special' config.sub/guess can use. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Wed, 2013-05-15 at 16:30 +0200, Thomas Petazzoni wrote: On Tue, 14 May 2013 23:53:44 -0400, Mike Frysinger wrote: yes, Gentoo fixed this for every package in our tree like 9 years ago FWIW, we do the same thing in Buildroot Yes, it is a very common hack in all of the distros. It would be nice if that wasn't necessary in the first place though. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Monday 08 October 2012 08:46:57 Paul Wise wrote: So, Debian is in the process of bringing up our upcoming arm64 port. Unfortunately we are also coming across lots of packages with rather outdated config.guess and config.sub files (see links below). We could patch every single package that contains config.guess and config.sub but that would be a lot of effort that doesn't scale. We could also patch our build tools but the problem would still exist for other distros. yes, Gentoo fixed this for every package in our tree like 9 years ago (we added a common function like 11 years ago that ebuilds could call manually, but we found that didn't scale). when you run a standard autoconf script, we automatically search for files named config.sub and config.guess and replace them with the up-to-date host copy. no checking or anything :). in hindsight, that seems like a bad idea, but in practice, i think we have yet to find a package that this doesn't actually work. and behold, no one has ever complained about config.sub not recognizing their mips or sparc or x86_64 or aarch64 system ever again. If anyone knows where config.guess and config.sub are installed on common platforms like the various Linux or BSD distributions, please let me know those locations. I have only the paths for Debian and Gentoo. if Gentoo is the only one that uses /usr/share/gnuconfig/ and every one else picked /usr/share/misc/, then i'll just move Gentoo. don't bother listing it in your patch. even then, many of the other paths (like internal automake/libtool) will work fine on Gentoo. we picked .../gnuconfig/ as it installs more than one file and FHS generally recommends that packages w/more than one file not go into .../misc/. -mike signature.asc Description: This is a digitally signed message part. ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, Oct 09, 2012 at 09:27:46AM +0800, Paul Wise wrote: On Mon, 2012-10-08 at 12:26 -0700, Russ Allbery wrote: Personally, I've already started converting every package I maintain that uses Autoconf to using dh_autoreconf during the build. Likewise. I wonder if that isn't a better long-term solution for Debian. It is, but for DFSG item 2 reasons rather than this. As a solution for this in Debian and outside Debian I don't think it scales as well. Within Debian we would need to make everything use debhelper and make debhelper do it by default, neither of which are likely. There are quite a few distros, including proprietary ones, so I don't think this approach scales outside of Debian either. ... One problem is that in new upstream versions of autoconf/automake/libtool there are sometimes slight incompatibilities, and you end up with shipping many different versions of each of these tools (even today Debian already ships 5 different versions of autoconf). E.g. putting automake 1.13 [1] as automake package into Debian would then require updating thousands of packages just for getting the whole archive to build again. bye, pabs cu Adrian [1] That will remove quite a few things marked as obsolete. -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
Adrian Bunk b...@stusta.de writes: One problem is that in new upstream versions of autoconf/automake/libtool there are sometimes slight incompatibilities, and you end up with shipping many different versions of each of these tools (even today Debian already ships 5 different versions of autoconf). E.g. putting automake 1.13 [1] as automake package into Debian would then require updating thousands of packages just for getting the whole archive to build again. This is a lot of work, yes. But personally I think it's valuable work that we shouldn't shy away from, and with which we can often help upstream. We do the same thing each time a new g++ is released; I don't think there's been a major g++ release that hasn't required some patches to one of the C++ packages I maintain. (autoconf-dickey is a separate matter; at this point, I think it's best to treat that as a permanent fork.) -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, Oct 09, 2012 at 10:17:44AM -0700, Russ Allbery wrote: Adrian Bunk b...@stusta.de writes: One problem is that in new upstream versions of autoconf/automake/libtool there are sometimes slight incompatibilities, and you end up with shipping many different versions of each of these tools (even today Debian already ships 5 different versions of autoconf). E.g. putting automake 1.13 [1] as automake package into Debian would then require updating thousands of packages just for getting the whole archive to build again. This is a lot of work, yes. But personally I think it's valuable work that we shouldn't shy away from, and with which we can often help upstream. ... Debian unstable usually contains code from the upstream stable branch, and even from that the latest release is often a few months old (no new upstream release or the latest is not yet in Debian). The issue might often already be fixed in the latest upstream unstable development, and it could easily result in most of the work being cherry-picking patches that are already upstream. ... (autoconf-dickey is a separate matter; at this point, I think it's best to treat that as a permanent fork.) (I'm currently working with Thomas towards getting more of his packages buildable with autoconf 2.69) cu Adrian BTW: Please send a copy of the mail to me when you reply to emails from me. -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
Does simple replacement of config.guess and config.sub constitute a useful port to this previously unencountered target? Is there really any viable substitute for re-autotooling the packages, while modifying configure.ac, Makefiles, and source code as found to be required? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 10/08/2012 06:46 AM, Paul Wise wrote: Hi all, So, Debian is in the process of bringing up our upcoming arm64 port. Unfortunately we are also coming across lots of packages with rather outdated config.guess and config.sub files (see links below). We could patch every single package that contains config.guess and config.sub but that would be a lot of effort that doesn't scale. We could also patch our build tools but the problem would still exist for other distros. I would like to get rid of this issue once and for all by making the update process for config.guess and config.sub once per machine or once per package instead of once per package. Not to discourage you, but I still see a fundamental problem, where things will just not scale for several more years (if ever). Your proposed patch will have no effect on packages that were shipped with a configure script generated by autoconf 2.69 or earlier (that is, they would only affect new packages built with the as-yet-unreleased autoconf 2.70). Therefore, you STILL have to touch every single package that was built with older toolchains to get them to take advantage of any new self-upgrading code path built into a newer autoconf. My initial approach in 2009 was to patch config.guess and config.sub to look for newer versions of themselves but the maintainer of these files wasn't happy with that approach. I recently re-contacted him about this issue and was suggested to patch autoconf. The approach I have taken is to make autoconf-produced configure scripts use the package-local config.guess/config.sub by default and if that fails then find the newest config.guess/config.sub in a number of paths on the system and use it. Is it safe enough to look at common system locations alone, or should we also be attempting a network lookup for the latest canonical upstream sources (of course, realizing that networking might not be available, so we must not trigger fatal failure just because a machine is off the grid at the time configure is run). I am not very familiar with autoconf internals, m4 or the intricacies of ancient shells, so I would very much appreciate a review of both the approach and my initial attempt at implementing this, please see the attached patch. I haven't yet looked at the patch; it's non-trivial enough that it will need copyright assignment to the FSF before it can even be considered. But I'm first worried about the bigger implications of what you intend to do about the fact that packages that were not built with autoconf 2.70 or later (assuming this patch makes it in) will still not benefit from this patch. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2012-10-08 at 10:22 -0600, Eric Blake wrote: Not to discourage you, but I still see a fundamental problem, where things will just not scale for several more years (if ever). Your proposed patch will have no effect on packages that were shipped with a configure script generated by autoconf 2.69 or earlier (that is, they would only affect new packages built with the as-yet-unreleased autoconf 2.70). Therefore, you STILL have to touch every single package that was built with older toolchains to get them to take advantage of any new self-upgrading code path built into a newer autoconf. I acknowledge this problem and there is no way to get around it. The patch is not meant to be useful for arm64, I'm taking a much longer term view here, the benefit is perhaps 5-10 years away. Once the patch is in a released version of autoconf it will percolate through the distributions archives as projects autoreconf with the latest autoconf and make new releases. Eventually we will have good coverage in most distributions. In the meantime, within Debian we will be pursuing both per-package updating of config.guess/sub and I'm also thinking about getting our binary package build toolchain to take that role, but I'm not sure how well that would be received within Debian or how well it would work. Is it safe enough to look at common system locations alone, or should we also be attempting a network lookup for the latest canonical upstream sources (of course, realizing that networking might not be available, so we must not trigger fatal failure just because a machine is off the grid at the time configure is run). For Debian, network access is usually disabled on our build daemons. I would discourage this without some checking of GPG signatures, otherwise it would be easy for network attackers to get arbitrary code execution on people's laptops and distribution build servers. I haven't yet looked at the patch; it's non-trivial enough that it will need copyright assignment to the FSF before it can even be considered. Personally I don't consider the patch to contain any creativity or to be copyrightable. I therefore consider that it is in the public domain and to the extent possible under law, I have waived[CC0] all copyright and related or neighboring rights to this work. If that isn't good enough for the FSF, then I'm willing to assign copyright as needed. CC0: http://creativecommons.org/publicdomain/zero/1.0/ But I'm first worried about the bigger implications of what you intend to do about the fact that packages that were not built with autoconf 2.70 or later (assuming this patch makes it in) will still not benefit from this patch. I hope I've addressed them to your satisfaction above. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2012-10-08 at 11:07 -0500, Bob Friesenhahn wrote: Does simple replacement of config.guess and config.sub constitute a useful port to this previously unencountered target? Yes. The problem is that we have to repeat this process for every package every time we want to bootstrap a new port or system. Or we can change every package to replace config.guess/sub. Or we can change the packaging building process for every distribution to replace config.guess/sub. Or we can just change autoconf so that it creates configure scripts that look for the latest config.guess/sub. I am pursuing all of these approaches, starting at autoconf. Is there really any viable substitute for re-autotooling the packages, while modifying configure.ac, Makefiles, and source code as found to be required? Not as yet, I'm hoping my patch will become that in the very long term. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, 9 Oct 2012, Paul Wise wrote: On Mon, 2012-10-08 at 11:07 -0500, Bob Friesenhahn wrote: Does simple replacement of config.guess and config.sub constitute a useful port to this previously unencountered target? Yes. The problem is that we have to repeat this process for every package every time we want to bootstrap a new port or system. Or we can change every package to replace config.guess/sub. Or we can change the packaging building process for every distribution to replace config.guess/sub. Or we can just change autoconf so that it creates configure scripts that look for the latest config.guess/sub. I am pursuing all of these approaches, starting at autoconf. While replacing config.guess/sub gets over the first hurdle, there are surely additional hurdles to be encountered which might render getting past the first hurdle to be moot. For example, libtool (also embedded in packages) includes platform-specific code keyed off of results from config.guess. Many configure scripts include peculiar code keyed off of results from config.guess. There is really no solid solution other than performing proper maintenance of the packages and sending patches to the upstream maintainer. For an exceedingly-rare platform like arm64, it is likely that the early ports will be of rather low quality and that quality will not improve until package maintainers take an interest, get access to target hardware, and make sure that their package works well on that target. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
Paul Wise pa...@bonedaddy.net writes: In the meantime, within Debian we will be pursuing both per-package updating of config.guess/sub and I'm also thinking about getting our binary package build toolchain to take that role, but I'm not sure how well that would be received within Debian or how well it would work. Personally, I've already started converting every package I maintain that uses Autoconf to using dh_autoreconf during the build. I wonder if that isn't a better long-term solution for Debian. config.guess/config.sub have caused the most frequent problems, but we've had problems in the past from old versions of Libtool as well, and dh_autoreconf resolves the entire problem (at least for packages for which it works). Paul, separately, if you haven't already, could you request that the Lintian checks for outdated config.guess/config.sub be updated for whatever version you need for arm64? We could also recommend dh_autoreconf at the same time, which might resolve a lot of these problems going forward. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
Bob Friesenhahn bfrie...@simple.dallas.tx.us writes: Does simple replacement of config.guess and config.sub constitute a useful port to this previously unencountered target? Believe it or not, yes, frequently it does. Note that this is specifically in the context of Debian, which means that all of these platforms are Linux and they're all using glibc. The variation between systems is therefore much less than one might expect, and less than a lot of packages using config.guess/config.sub are adjusting for. There are a lot of packages that have one case that works on all Linux systems, and those will generally work fine on a new Debian architecture as long as config.guess/config.sub doesn't explode when attempting to determine the triplet. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, 9 Oct 2012, Paul Wise wrote: On Mon, 2012-10-08 at 11:07 -0500, Bob Friesenhahn wrote: Does simple replacement of config.guess and config.sub constitute a useful port to this previously unencountered target? Yes. The problem is that we have to repeat this process for every package every time we want to bootstrap a new port or system. Or we can change every package to replace config.guess/sub. Or we can change the Would it help if Autoconf supported environment variables to support specifying the config.guess and config.sub scripts to use (similar to CONFIG_SITE and CONFIG_SHELL)? For example, there could be CONFIG_SITE and CONFIG_SUB environment variables. This approach would allow the package build wrapper to cause updated scripts to be used without needing to replace stale files which might happen to be in the package. It seems easier for the package build system to specify what it wants to be used rather than hope that rules built into the package will select the desired version. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 8 Oct 2012, Bob Friesenhahn wrote: CONFIG_SITE and CONFIG_SHELL)? For example, there could be CONFIG_SITE and CONFIG_SUB environment variables. This approach would allow the package I meant CONFIG_GUESS and CONFIG_SUB of course. :-) Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 08 Oct 2012, Russ Allbery wrote:
Personally, I've already started converting every package I maintain that
uses Autoconf to using dh_autoreconf during the build. I wonder if that
isn't a better long-term solution for Debian. config.guess/config.sub
have caused the most frequent problems, but we've had problems in the past
from old versions of Libtool as well, and dh_autoreconf resolves the
entire problem (at least for packages for which it works).
Paul, separately, if you haven't already, could you request that the
Lintian checks for outdated config.guess/config.sub be updated for
whatever version you need for arm64? We could also recommend
dh_autoreconf at the same time, which might resolve a lot of these
problems going forward.
Well, as far as I am concerned, we should axe from the [next] Debian stable
distro anything that doesn't retool completely before the build, IMO just
updating config.sub/guess is not nearly enough.
That said, Debian rules for packages *really* won't help a large class of
people: those who are not doing Debian package work...
And BTW, I am perfectly fine with issuing debian-stable updates to
autotools-dev (the Debian package that contains the /usr/share/misc/
config.{sub,guess}), but someone has to convince the release managers that
this is acceptable. We _really_ should do this, since people do develop
software using Debian...
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2012-10-08 at 12:26 -0700, Russ Allbery wrote: Personally, I've already started converting every package I maintain that uses Autoconf to using dh_autoreconf during the build. Likewise. I wonder if that isn't a better long-term solution for Debian. It is, but for DFSG item 2 reasons rather than this. As a solution for this in Debian and outside Debian I don't think it scales as well. Within Debian we would need to make everything use debhelper and make debhelper do it by default, neither of which are likely. There are quite a few distros, including proprietary ones, so I don't think this approach scales outside of Debian either. config.guess/config.sub have caused the most frequent problems, but we've had problems in the past from old versions of Libtool as well, and dh_autoreconf resolves the entire problem (at least for packages for which it works). Thanks, I guess I should prepare a patch for the libtool artefacts too. Paul, separately, if you haven't already, could you request that the Lintian checks for outdated config.guess/config.sub be updated for whatever version you need for arm64? We could also recommend dh_autoreconf at the same time, which might resolve a lot of these problems going forward. Thanks for the suggestion, filed: http://bugs.debian.org/690014 -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2012-10-08 at 18:40 -0300, Henrique de Moraes Holschuh wrote:
Well, as far as I am concerned, we should axe from the [next] Debian stable
distro anything that doesn't retool completely before the build, IMO just
updating config.sub/guess is not nearly enough.
I think thats going a bit far, especially since there is widely varying
opinion within Debian about if retooling is a good idea or not. I think
retooling is important for various reasons but not important enough to
lose the software from maintainers who disagree.
That said, Debian rules for packages *really* won't help a large class of
people: those who are not doing Debian package work...
Good point!
And BTW, I am perfectly fine with issuing debian-stable updates to
autotools-dev (the Debian package that contains the /usr/share/misc/
config.{sub,guess}), but someone has to convince the release managers that
this is acceptable. We _really_ should do this, since people do develop
software using Debian...
I think they would be open to this. Please file a bug so we can get this
into the next point release:
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
--
bye,
pabs
http://bonedaddy.net/pabs3/
signature.asc
Description: This is a digitally signed message part
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Mon, 2012-10-08 at 13:52 -0500, Bob Friesenhahn wrote: While replacing config.guess/sub gets over the first hurdle, there are surely additional hurdles to be encountered which might render getting past the first hurdle to be moot. Agreed, the key here is to not give up before starting. I'll probably work on other issues as I find out about them. The copies of libtool parts are probably the next thing to work on. For example, libtool (also embedded in packages) includes platform-specific code keyed off of results from config.guess. Many configure scripts include peculiar code keyed off of results from config.guess. In that case I should revise my patch to always use the latest available config.guess instead of always trying the one in the package first. Thanks for the info, I was a bit worried about that issue. There is really no solid solution other than performing proper maintenance of the packages and sending patches to the upstream maintainer. That doesn't scale to 30K packages, each with different maintainers both upstream and Debian. Not to mention all the other distros. For an exceedingly-rare platform like arm64, it is likely that the early ports will be of rather low quality and that quality will not improve until package maintainers take an interest, get access to target hardware, and make sure that their package works well on that target. The people who are working on arm64 are employees of ARM Ltd and have many years of experience with ARM stuff in both Debian and upstream. I trust them to get the port right the first time. As for the packages, I would guess that the other 64-bit Debian ports (ia64, amd64 etc) we have had would have fixed most 64-bitness issues years ago. I would hope that the port will be ready by the time ARMv8 capable SoCs are shipping. -- bye, pabs http://bonedaddy.net/pabs3/ signature.asc Description: This is a digitally signed message part ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
+++ Russ Allbery [2012-10-08 12:32 -0700]: Bob Friesenhahn bfrie...@simple.dallas.tx.us writes: Does simple replacement of config.guess and config.sub constitute a useful port to this previously unencountered target? Believe it or not, yes, frequently it does. Note that this is specifically in the context of Debian, which means that all of these platforms are Linux and they're all using glibc. Indeed. In more than 90% of cases this is all that was required, assuming the package cross-built at all (currently everything is cross-built as there is no actual arm64 hardware anywhere). yes, a proper autoreconf is better for lots of reasons but it doesn't really make any difference for our purposes. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
