Weekly Edition
Return to the Development page
| |||||||||||||
Quotes of the week
While this change is "obviously correct", every programmer has also had
the experience of spending hours trying to find a bug, only to discover
it was an invisible one-character typo. Thus every programmer should
also know that "obviously correct" and "correct" are not quite the same.
— Matt Mackall
What we do to deprecate functionality in X is we break it accidentally, we
wait three or four years, see if we've gotten any bug reports—if we've
gotten any bug reports we may actually go fix it; if we've gotten no
bug reports we silently delete the feature.
— Keith Packard, at LCA 2013, shortly before suggesting that the kernel adopt the same approach.
If you are an upstream of a software that uses autoconf - Please run autoreconf against autotools-dev 20120210.1 or later, and make a release of your software.
— Riku Voipio
Aarch64 porters will be grateful as updated software trickles down to distributions. (Log in to post comments)
Quotes of the week Posted Feb 7, 2013 2:30 UTC (Thu) by jcm (subscriber, #18262) [Link]
Thank you Jake+Jon+team for the AArch64 mention!
Quotes of the week Posted Feb 7, 2013 10:02 UTC (Thu) by epa (subscriber, #39769) [Link]
Why are we still running configure scripts included as part of the source tarball? Wouldn't it make more sense to distribute a source tree without any generated files, and the person building it will run autoconf? In another era it was useful to have a source package that didn't require anything beyond standard Unix and a half-decent compiler, but nowadays all distributions include packages for autotools.
Quotes of the week Posted Feb 7, 2013 10:09 UTC (Thu) by mpr22 (subscriber, #60784) [Link] The conservative distributions don't have the latest autotools.
Quotes of the week Posted Feb 7, 2013 10:27 UTC (Thu) by epa (subscriber, #39769) [Link]
I imagine the conservative distributions don't build packages for AArch64 either.
Quotes of the week Posted Feb 7, 2013 10:44 UTC (Thu) by mpr22 (subscriber, #60784) [Link] My imagination agrees with yours on that point. However, users of any given conservative distribution may well want to build software whose autotools input files are aligned to a later version of autotools than the one shipped by that distribution. (Why yes, I do speak from experience.)
Quotes of the week Posted Feb 7, 2013 13:35 UTC (Thu) by nhippi (subscriber, #34640) [Link]
Distributing source tree without generated files would break builds on non-linux platforms.
Linux distributions can (and often do) run auto(re)conf as part of package build. But that has some gotchas - sometimes clueless upstream edits the generated files directly or does some other non-standard magic. So it needs to be done on package-by-package cases and not unilaterally over the distributions.
As pointed by a commenter on my blogpost, this could be permanently fixed with the patch suggested to config-patches list - where /usr/share/misc/config.sub is used instead of source package copy. However, the upstream has apparently ignored the suggestion.
Quotes of the week Posted Feb 7, 2013 14:45 UTC (Thu) by epa (subscriber, #39769) [Link]
I wonder what non-Linux platforms would really break. Very few packages these days target crusty classical Unix with K&R compiler, non-GNU make, and so on. If you want to get anything done you have to have a dozen build tools. So why not require one more and expect the user to have autotools installed?
Quotes of the week Posted Feb 7, 2013 16:04 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Carefully. Next you'd suggest that 500kb "configure" files in bash are not the best way to handle the build.
Quotes of the week Posted Feb 7, 2013 16:20 UTC (Thu) by ortalo (subscriber, #4654) [Link]
Indeed, it still astonishes me that such a configure&build system survived for 20 years nearly unchallenged.
After all, CVS, another tool from the same era, has already been obsoleted several times...
(NB: Notice how I subrepticely sneak a second 20 years-old flamewar into yours... ;-))
Quotes of the week Posted Feb 7, 2013 16:18 UTC (Thu) by mpr22 (subscriber, #60784) [Link] Which version of autotools? (If you aren't shipping the finished 'configure' script, it matters.)
Quotes of the week Posted Feb 8, 2013 10:59 UTC (Fri) by epa (subscriber, #39769) [Link]
Hmm, I imagined that you could require autotools version N or later, but if you are implying that certain setups require a single fixed version of autotools, I can see that distributing the generated configure script makes life easier for everyone.
Quotes of the week Posted Feb 8, 2013 11:14 UTC (Fri) by mpr22 (subscriber, #60784) [Link] A quick look at cjwatson's comment further down the page suggests that there has been compatibility breakage (i.e. version X.Y's input files aren't compatible with version X.Y+[small N]) at least once. That aside, my fundamental objection is that I absolutely do not (and never will) trust J. Random Linux Developer to know or care what version of autotools is in current Debian-stable or current RHEL even if their program has no legitimate impediment (needing newer versions of things the program actually uses is legitimate; needing newer autotools even though the actual program would build just fine if the build system would let you get as far as having a Makefile is not) to being built on those platforms.
Quotes of the week Posted Feb 8, 2013 13:47 UTC (Fri) by epa (subscriber, #39769) [Link]
I see... so you would not want developers to ship source tarballs requiring autotools version N or later, where N is just the version which the developer happens to have on their own machine. You would prefer them to either carefully consider which versions are likely to be available in the wild, and restrict themselves to that version - which isn't going to happen - or else sidestep the issue by running autoconf themselves and distributing the generated configure script.
My point of view is that I don't see autotools as that different from all the other stuff you need to build a program, which has equally hairy dependency requirements. A developer might write some C++ which requires the latest gcc, even though Debian stable is including an older version. We handle that in various ways, including making it possible to install a newer gcc if you need it, and I think the same can apply to autotools.
Quotes of the week Posted Feb 8, 2013 15:10 UTC (Fri) by mpr22 (subscriber, #60784) [Link] I see a very large qualitative difference between "the program depends on features of the latest library or language-processor versions" and "the program's build system relies on a version-sensitive build system facilitator that produces version-insensitive output; the program itself can be built with no trouble using a five-year-old compiler and three-year-old libraries if the developer can be bothered to pre-run the build system facilitator and include its output in the tarball". Which is the situation I have run into that makes me so hostile to the "stop shipping 'configure'; add autotools version N or later to the build requirements" proposal.
Quotes of the week Posted Feb 8, 2013 17:38 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
I've been bit by this a few times, it's very annoying to have an app that you can download a tarball for and compile it, but not check out of git and compile it (because configure is a generated file and therefor not stored in git)
Quotes of the week Posted Feb 8, 2013 18:05 UTC (Fri) by raven667 (subscriber, #5198) [Link]
Maybe there should just be recognition that the source tree and tarball/package may be two (similar) but distinct things, one is for editing and the other is an installable artifact.
Quotes of the week Posted Feb 11, 2013 11:03 UTC (Mon) by epa (subscriber, #39769) [Link] Maybe there should just be recognition that the source tree and tarball/package may be two (similar) but distinct things, one is for editing and the other is an installable artifact.This makes a lot of sense. The issue is who is responsible for generating the tarball from the source tree? If it is the upstream developer, then we have situations like the one that prompted this 'quote of the week', where upstreams have to be prodded to rerun autoconf to add support for a new processor. It might be better for upstream to concentrate on developing the software and blessing particular versions as 'releases' (probably using tags in the version control system), while those who are interested in packaging and installing it can generate the tarball or package from the upstream source.
Quotes of the week Posted Feb 11, 2013 14:58 UTC (Mon) by raven667 (subscriber, #5198) [Link]
I still think that you want the upstream making release tarballs but a concerned packager can still download the source and make their own release using updated autoconf tools if necessary. There might even be something to contribute back to the main developers, like an RPM spec file or other packaging info
Quotes of the week Posted Feb 8, 2013 15:11 UTC (Fri) by raven667 (subscriber, #5198) [Link]
That's not "sidestepping" the issue, I believe that's the intended workflow for autotools and configure scripts. You run whatever the latest autotools is so that you can teach your configure script everything it needs to know to do feature detection on a wide variety of platforms, and those platforms only need a shell and basic tools, plus the dependancies for your program itself.
Quotes of the week Posted Feb 7, 2013 18:14 UTC (Thu) by zlynx (subscriber, #2285) [Link]
Please don't.
I detest running into software packages that would build perfectly fine on CentOS 5, if only they had included a configure script.
I end up hand-hacking the autotools scripts to rip out the incompatible sections or sometimes trying to get autotools installed in a private directory, or the easiest solution, build the configure script on Fedora 18 and copy it over.
Just include the configure script. If you're using autotools at all, use it in the way it was intended.
Quotes of the week Posted Feb 8, 2013 1:19 UTC (Fri) by cjwatson (subscriber, #7322) [Link]
A sensible compromise is for upstream to distribute autotools output with their tarballs, but for distributions to regenerate it. dh-autoreconf does an excellent job of helping Debian developers do this (I've been converting my packages to it), but I know at least some other distributions have similar helpers.
My experience is that you cannot do this automatically across the board. I've had to take a number of slightly different approaches in my packages (some are sufficiently ancient to require porting from autoconf 2.13; some require invocation of ./autogen.sh or similar rather than autoreconf; some don't use automake or libtool but do use AC_CANONICAL_* in which case autoreconf does not automatically update config.{guess,sub}). This has convinced me that package maintainers do need to do some work here, but that it's worthwhile.
Quotes of the week Posted Feb 9, 2013 14:19 UTC (Sat) by alfille (subscriber, #1631) [Link]
These are all great comments.
As a developer with a package that uses autoconf that someone created for me and gets updated by guesswork, can I suggest one of you commenters write a brief description of the preferred distribution workflow?
The autoconf documentation is written for experts, and frankly, my interest is in my code, not learning an arcane configuration system.
Quotes of the week Posted Feb 9, 2013 14:53 UTC (Sat) by cortana (subscriber, #24596) [Link]
Run 'make dist' and it will generate foo-0.1.tar.gz file for you containing all the right stuff.
You can also run 'make distcheck' which will ensure that the generated archive will actually work--it builds the package, runs the tests, installs the package, uninstalls it, etc.
|
|||||||||||||