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
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
