> On Nov 19, 2014, at 12:56 AM, Erik Joelsson <erik.joels...@oracle.com> wrote: > > > On 2014-11-18 19:09, Christian Thalinger wrote: >>> On Nov 18, 2014, at 7:36 AM, Magnus Ihse Bursie >>> <magnus.ihse.bur...@oracle.com> wrote: >>> >>> On 2014-11-18 01:59, Christian Thalinger wrote: >>>>> On Nov 17, 2014, at 4:11 AM, Magnus Ihse Bursie >>>>> <magnus.ihse.bur...@oracle.com> wrote: >>>>> >>>>> On 2014-11-14 21:44, Dean Long wrote: >>>>>>> The distribution exception is there exactly since anyone should be able >>>>>>> to distribute the files with their configure script. That does not mean >>>>>>> that you are allowed to edit it, though. >>>>>> What if we require Autoconf to be installed on the host? Does that >>>>>> solve any problems? >>>>> No, unfortunately not. >>>> Why not? >>> Autoconf picks up these files automatically from the build-aux directory. >>> That's also the reason we need to rename the original files and provide >>> wrappers with the same name, since we can't even redirect that >>> functionality to a file with another name. >> So do I understand you correctly that the files we need are automatically >> copied into the workspace but since we want to use our own, old versions we >> renamed them and use these instead? > No, I will try to clarify. > > Autoconf is a tool that takes one (or more) input files (written in m4 macro > language) and generates a shell script, often named "configure". This shell > script is what you would typically run to configure your project. Autoconf > defines an API of m4 macros specifically for configure scripts which is > basically what makes it useful. Most of these macros are expanded into the > generated configure script. > > However, for reasons unknown to us, some of the more complex functionality > has been split out into separate shell script "library" files. These library > files, often referred to as "build-aux" are supposed to be distributed with > the project source code, along with the generated configure script. We > distribute them in common/autoconf/build-aux. These files can be found in the > source distribution of autoconf or by downloading from the official scm repo > for them. They are not part of the binary distribution of autoconf on my > Ubuntu system at least.
Well, that’s because config.guess and config.sub are part of automake: http://git.savannah.gnu.org/gitweb/?p=automake.git;a=tree;f=lib;hb=HEAD <http://git.savannah.gnu.org/gitweb/?p=automake.git;a=tree;f=lib;hb=HEAD> and installed e.g. in this directory on Solaris: $ ls /usr/share/automake-1.10/ acinstall* ansi2knr.1 Automake/ config-ml.in config.sub* depcomp* INSTALL mdate-sh* mkinstalldirs* symlink-tree* ylwrap* am/ ansi2knr.c compile* config.guess* COPYING elisp-comp* install-sh* missing* py-compile* texinfo.tex $ automake --add-missing makes a copy of these files, if necessary: configure.ac:3: the top level configure.ac:3: installing `./config.sub' configure.ac:3: installing `./config.guess' $ ls -l config.* lrwxrwxrwx 1 cthaling staff 37 2014-11-19 16:26 config.guess -> /usr/share/automake-1.10/config.guess* lrwxrwxrwx 1 cthaling staff 35 2014-11-19 16:26 config.sub -> /usr/share/automake-1.10/config.sub* > For this reason, it wouldn't help requiring autoconf to be installed as that > wouldn't provide the files. > > For non GPL projects to be able to distribute the files in build-aux, they > come with a special exception to GPL, which basically allows them to be > freely distributed as long as they are part of a configure script. This > exception does not seem to give any exception for deriving work from them. > > /Erik
