autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: configure.ac, Makefile.am question


From: Eric Blake
Subject: Re: configure.ac, Makefile.am question
Date: Thu, 21 Aug 2008 07:24:35 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080708 Thunderbird/2.0.0.16 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to address@hidden on 8/21/2008 6:51 AM:
>> If it's _his_ source code (and assuming that _he_ licensed it GPL), he can 
>> distribute whatever set of files he chooses.  The restriction applies for 
>> files that he gets from someone else.
>>
> yes it's pure my code and i haven't licenced it yet(didn't have time for 
> that).

Please consider using the GPL, then, as it affords your users the most
freedom in using your software.  However, autoconf _does_ allow you the
option of using another license of your choosing.

> Having
> cleared that, has anyone hints for the minimum set of files for autotooling?

Your terminology is a bit confused.  The minimum set of files needed for
autotooling is configure.ac and Makefile.am (ie. the input files used by
autoreconf --install); other files like config.h.in are optional.  But it
sounds like you are asking for what you can avoid distributing, if you
want to make it impossible for the user to re-autotool your package.

> Besides of those files mentioned in subject, i'd not like to deliver any 
> files which
> could be recovered by ./configure.

The only files built by ./configure are Makefile and anything else listed
in AC_CONFIG_FILES.  And those generated files should NOT be distributed
in the first place, only their inputs.   In other words, the generated
Makefile on your platform will not work on someone else's platform;
./configure requires that you distribute Makefile.in and then it builds
Makefile.  But automake already does this for you (distributes Makefile.in
but not Makefile).  Meanwhile, other files which are added by automake
during autotooling, such as config.guess, are not regenerated by
./configure; if you fail to distribute them after automake has gone to the
effort of including it, you are distributing a broken package.

> As files are so many and I am unexperienced
> in autotooling, it gets difficult to test one by one.

I repeat my first observation: distribute those files that Automake
selects for you, and don't waste your time trying to second-guess things.
 That is the easiest course for you, and gives your users the most
freedom.  And just because you distribute these extra files does not mean
the user has to care about them; the autotools intentionally produce
output files that do not rely on the existence of the autotools to be
useful on the user's machine.

If you are really worried about the minimum distribution, then only give
your users pre-built binaries (without seeing any of your source); but
don't use the GPL in that case.  And taken to that extreme, you won't even
have to use autotools (if you don't distribute source, then using
autotools to find out about the platform where you pre-build binaries is
overkill).  Sound crazy?  Then realize that if you care about giving your
users the ability to recompile your program and fix bugs, you shouldn't
limit their ability to re-autotool your package.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkitbJMACgkQ84KuGfSFAYDwjwCgn8BU0B0QIFiLWmSwhR4Lgxkf
vFgAoI9scny4bzlZiBac0reYEicTDopP
=0DYx
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]