Re: [RFC] pass #2 at getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, 2012-10-09 at 07:14 +0200, Ralf Corsepius wrote: I don't like this approach, because I think you are missing that config.sub and config.guess have only been overwritten as part of autoreconf -f (and not of autoreconf). This allows package upstreams to implement customized versions of both of these scripts. I hadn't considered custom versions, but that sounds icky. I figure in these cases they can bump their timestamp to -99-99 if they want to never use the official versions of these files, I can't think of a case where they would want that though. The use-cases you mention below, they probably just want the latest versions from config.git rather than to always use their own. Though such cases are rare to find in mainstream packages, theses case are quite common in cases to toolchain/OS implementors and cross-compilation scenarios. I think people needing these particular use-cases can use my proposed mechanism instead, which should work better for them anyway since they don't need to modify every package being built nor modify their build system. FWIW: Apart of this, in comparable situations in the past, on Red Hat based distros, IIRC, RedHat had chosen to copy their versions of config.guess+config.sub as part of their build-process [1] by default[2]. This would be comparable to the dh_something others mentioned before in this thread. Could you give some more details? Were the RH versions of config.guess and config.sub modified in any way or were they just newer versions from GNU config CVS/git? PS: Please CC me in reply. -- 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
Wholesale sharing of config.cache across many packages
Hi all, in my current continuous integration environment we run configure scripts on the order of 10^5+ times a day. Each build starts in a clean workspace that is almost akin to a fresh Linux install. We don't ship a config.site, and we build many packages in parallel. I tried to use the same --cache-file to speed things up. I wrap my ./configure invocations with a small dance that can be summarized like this: if test -f /tmp/config.cache; then # We already have something TMP_CACHE=`mktemp` cp /tmp/config.cache $TMP_CACHE fi if ./configure --cache-file=$TMP_CACHE [..other flags..]; then # Success mv $TMP_CACHE /tmp/config.cache fi rm -f $TMP_CACHE This way each run of configure operates on its own file to avoid race conditions, but benefits from the cache variables populated by previous runs. Of course in practice the dance above is also written in a way to be atomic, the code above is a simplification. This works fine except for one thing: if one package decides to invoke configure with different CFLAGS/CXXFLAGS (or any other precious variable for that matter), I get the annoying: configure: loading cache /tmp/configure.cache.ea93QN configure: error: `CFLAGS' has changed since the previous run: configure: former value: `-g' configure: current value: `-g -Wall -Werror' In http://lists.gnu.org/archive/html/autoconf/2011-03/msg00042.html someone asked whether there is a programatic way to do something when this situation arises – without duplicating all the code in configure to catch this case, obviously. I'm not aware of any, but I'm looking for a workaround. Other than parsing's configure output when it errors out and iterating again after patching the config.cache file, which would be a very ugly kludge. Any suggestions? Thanks in advance. -- Benoit tsuna Sigoure ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
Re: [RFC] pass #2 at getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On 10/08/2012 10:49 PM, Paul Wise wrote: On Mon, 2012-10-08 at 22:03 -0600, Eric Blake wrote: I still prefer the idea of being able to set an environment variable, $CONFIG_GUESS, rather than going hunting ourselves. Then, porting to a new config.guess script is a matter of calling: ./configure CONFIG_GUESS=/path/to/new/version rather than hoping that a hard-coded hunt will find the new config.guess appropriate for the system wanting the upgrade path. Changing the command-line to ./configure doesn't scale. Exporting an environment variable possibly sounds like an approach some folks would need, Then call: CONFIG_GUESS=/path/to/new/version ./configure and make CONFIG_GUESS a precious variable within configure. so I have added it in the attached patch. For Debian it would be easiest to just install the autotools-dev package in build chroots (config.guess and config.sub are placed in /usr/share/misc) since it doesn't require fiddling about with configuration files for build daemon software, which usually doesn't leak random environment variables into the build process. I still stand by my opinion that an env-var is sufficient, and we do not need a path walk. -- 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 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
[Autoconf] Including and extracting jar files in Makefile.am
Dear Sir/Madam, I am trying to install jar files in Makefile.am. My project needs to be extracted before make. How can I include jar files and extract them before running make in my project? -- Regards Sujit Kisan Devkar =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
