[RFC] X.Org minimum requirements for Autotools policy review
memsize at videotron.ca
Fri Oct 25 17:13:56 CEST 2013
On 13-10-25 01:49 AM, Matthieu Herrb wrote:
> On Thu, Oct 24, 2013 at 02:17:48PM -0400, Gaetan Nadon wrote:
>> The current Autotools minimum requirements are stated in
>> * autoconf (2.60)
>> * automake (1.10)
>> * libtool (1.5)
>> These requirements should be revised periodically. A number of factors
>> would motivate such a revision:
>> * The oldest autotool one can still use today dates from 2003.
>> * Some macros we use today have been deprecated for ten years and are
>> planned to be removed from future versions of autotools (that are
>> now available today).
>> * It is nearly impossible for a developer to know if a feature he is
>> using today is available in the oldest tool one can use.
>> * Our dependencies and newly created modules are coding against what
>> is available on their computer and perhaps not even aware of those
>> minimum requirements.
>> *Package* *autoconf* ac_prereq Really needs *automake*
>> libdrm 2.63 2.62 1.10 2.2
>> mesa not specified 2.61 1.10 2.2
>> libevdev 2.64 2.62 1.11 2.2
>> Others 2.60 2.60 1.10 1.5
>> Current Versions for Autoconf, Automake and Libtool timeframe:
>> Autoconf version 2.60 Dating 2006
>> Autoconf version 2.62 Dating 2008
>> Automake version 1.10.x Dating 2006 to 2008
>> Requires autoconf >= 2.60
>> Automake version 1.11.x Dating 2009 to 2012
>> Requires autoconf >= 2.62 to >= 2.68
>> Libtool version 1.5:
>> version 1.5 to 1.5.26 Dating 2003 to 2008
>> Require autoconf >= 2.50
>> Libtool version 2.x:
>> version 2.2 to 2.4.2: Dating 2008 to 2011
>> Requires autoconf >= 2.59 to >= 2.62
>> 1. We should prereq libtool 2.2 as a minimum (available since 2008).
>> 2. We should prereq autoconf 2.62 as a minimum (available since 2008).
>> Keeps us in the same time period and is required by automake 1.11.
>> 3. We should prereq automake 1.11 (available since 2009). Keeps us in
>> the same time period.
>> If the policy is changed, the wiki will be updated.
> This would be ok for OpenBSD. I currently use automake 1.12 and
> autoconf 2.69 for the packages there, but we have newer versions in
> the ports tree too.
>> GPLv3 Autoconf licensing still an issue?
>> A couple of years ago, some platforms declared they were unable to
>> ship any software package if it was licensed under GPLv3. This is
>> the case for Autoconf 2.62 and I recall XCB had to rollback to 2.60.
>> Anyone knows if this has been rosolved?
>> Excerpt from
>> 2.61 is the last pure-GPLv2 version
>> 2.62 is the first version that included GPLv3 tools to build
>> autoconf, but the installed bits were all GPLv2
>> 2.65 is the first version to be completely GPLv3
>> In order to use 2.62, I would need to build it. In order to
>> build it, I would have to accept GPLv3 (which is not acceptable).
>> In order to use 2.65, I would need to accept GPLv3 (which is not
>> The files generated by autoconf (ie ./configure) are not GPL'd.
> Hmm... while checking the issue above, I just discovered that since
> xorg-macros 1.13 there is GPLv3 code there. This is a bigger
> concern, For now it the only bits of v3 licenced code that leaks
> into the Xorg files in OpenBSD, and yes if we could get rid of it it
> would be better.
My question only initially concerned "building using autoconf >= 2.62",
but I had not thought about the GNU Autoconf Archive macros. There are
a few instances where xorg has copied and modified AX_* macros or simply
included them in /m4. Reading the licence text, it makes the same
Exception to the macros than it does for the rest of the generated files.
If an organization is accepting the use of GPLv3 autoconf package to
build and distribute software, the use of macros from the Autoconf
Archive should be acceptable. After all, they are extensions to the
Autoconf package. Each organization would have to make such a call and
not take my word for it :-)
Note that Mesa is including AX_PTHREAD with the same license.
Speaking of Mesa, you may be concerned that part of Mesa source code is
GPL v3. I suppose it taints xorg which links to mesa. That was another
question I had.
More information about the xorg-devel