Re: automake -a
Marc Glisse marc.gli...@inria.fr writes: It seems that it would be easiest to do what the comment in .bootstrap says, remove those files from the repository and use automake -a to make sure we have a consistent version of everything (no -f so it doesn't override our specific INSTALL, config.guess, etc). Makes sense to me, as long as removing files in the repo is decided on a case-by-case basis. E.g., I think the COPYING file should stay in the repo, even if automake -a currently installs an identical file. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: automake -a
On Mon, 23 Sep 2013, Niels Möller wrote: Marc Glisse marc.gli...@inria.fr writes: It seems that it would be easiest to do what the comment in .bootstrap says, remove those files from the repository and use automake -a to make sure we have a consistent version of everything (no -f so it doesn't override our specific INSTALL, config.guess, etc). Makes sense to me, as long as removing files in the repo is decided on a case-by-case basis. Do you agree with the initial list I proposed? E.g., I think the COPYING file should stay in the repo, even if automake -a currently installs an identical file. Ah, I hadn't noticed COPYING, precisely because the file is identical ;-) Ok with keeping it if you want to... I did an automake -a -c -f, followed by hg status to see what had changed, and pruned that list a bit. -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: automake -a
On Mon, 23 Sep 2013, Vincent Lefevre wrote: On 2013-09-23 15:37:20 +0200, Marc Glisse wrote: On Mon, 23 Sep 2013, Niels Möller wrote: E.g., I think the COPYING file should stay in the repo, even if automake -a currently installs an identical file. Ah, I hadn't noticed COPYING, precisely because the file is identical ;-) Ok with keeping it if you want to... I think that you must keep it: you choose the license, not the autotools developers. I would assume that the autotools get the information on which licence is wanted from somewhere and don't add a random licence, but keeping it sounds natural indeed. I did an automake -a -c -f, followed by hg status to see what had changed, and pruned that list a bit. How about doing something like the autogen.sh script proposed by Daniel Richard G. for MPFR: #!/bin/sh # autoreconf -f will clobber our INSTALL file with a generic one if we # don't move it out of the way mv -f INSTALL INSTALL.$$.tmp autoreconf -v -f -i -W all rm -f INSTALL mv -f INSTALL.$$.tmp INSTALL rm -rf autom4te.cache We could. I think avoiding -f is safer. Starting from a clean checkout when you upgrade your autotools isn't that hard. I hadn't realized that autoreconf -i -s would call automake -a, which is good. So a minimal change to use autoreconf -i -s instead of our current long line would be nice. A script could also be used to get the latest config.guess as configfsf.guess, but we probably don't want that (have to make sure it interacts ok with the specialized config.guess). -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: automake -a
On Mon, 23 Sep 2013, Niels Möller wrote: Marc Glisse marc.gli...@inria.fr writes: Do you agree with the initial list I proposed? I don't think I've seen an explicit list. remove: doc/mdate-sh doc/texinfo.tex install-sh missing ylwrap -- Marc Glisse ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
