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
