Comments on comparison with autoconf-archive about not-autotools HOT 8 CLOSED

What I struggle a bit to understand is the main point you want to make in this discussion.

My point: as far as I can tell, the differences between Autoconf Archive and not-autotools are less significant than you say, and I think that's important.

Your opinion is (reasonably enough!) that the differences are exactly as you say.

The reason we can hold these different opinions is because of the lack of explicit direction in the autoconf-archive documentation; we interpret the available evidence differently.

If I were to try to resolve our difference of opinion, I would do it by asking the autoconf-archive maintainers explicitly to document how they think the project should be used. So, I shall do that. Meantime, I am closing this issue, as you have convinced me that your interpretation is entirely reasonable (and may well be correct).

from not-autotools.

@rrthomas You don't need to copy and paste Autoconf Archive macros. Once you install the package aclocal will find them for you.

from not-autotools.

@madmurphy, the installation instructions for autoconf-archive are pretty brief and vague, but it does say:

[The ]repository can be cloned anonymously, which is probably the most convenient way to access the Archive. 
…
For the benefit of everyone who doesn’t use Git, traditional release archives can be downloaded from any GNU mirror

The implication is that one does not normally install a package, though this is certainly possible, and some GNU/Linux distros package it. However, this is just a convenience to developers: it would be contrary to the GNU Coding Standards to have autoconf-archive as a build-time dependency; as you observe, you run aclocal, and thereby copy the macros you use into your project.

So, this sentence:

The Autoconf Archive expects users to install a package that makes some new macros automatically available.

is misleading, as I don't believe one can say that the Autoconf Archive expects users (i.e. developers) to install a package. In any case, simply copying the relevant macros into one's project works just fine.

from not-autotools.

The implication is that one does not normally install a package, though this is certainly possible, and some GNU/Linux distros package it. However, this is just a convenience to developers: it would be contrary to the GNU Coding Standards to have autoconf-archive as a build-time dependency; as you observe, you run aclocal, and thereby copy the macros you use into your project.

You might not have caught the spirit of the Autoconf Archive. A developer installs it on his/her machine – so that manual copying-pasting of single macros is not required – then launches autoreconf, so that a configure script for the final user is generated, which will not depend on Autotools or Autoconf Archive.

is misleading, as I don't believe one can say that the Autoconf Archive expects users (i.e. developers) to install a package

Again, you are free to copy manually as many macros as you want, but “the spirit” of the Autoconf Archive is to avoid that you have to do that.

In any case, simply copying the relevant macros into one's project works just fine.

I have no doubts about that.

from not-autotools.

You might not have caught the spirit of the Autoconf Archive. A developer installs it on his/her machine – so that manual copying-pasting of single macros is not required

I can find no evidence that this is the intended way to use autoconf-archive, as I say (and I've been a user and contributor for many years!). Can you point to something in the Autoconf Archive documentation that suggests this is the intended way to use it?

In any case, simply copying the relevant macros into one's project works just fine.

I have no doubts about that.

This then suggests that it's not a "difference" from not-autotools; rather, Autoconf Archive has a feature that not-autotools lacks, namely that it can be used in an additional way.

Sorry if this seems rather pedantic, but I think it's important: it suggests, as I say, that the two projects at the very least can be used in pretty much exactly the same way, without any problem. This is a good thing: it means that a developer who is familiar with not-autotools can immediately use autoconf-archive in the same way, and also that there is a single technique by which both can be combined.

from not-autotools.

I can find no evidence that this is the intended way to use autoconf-archive, as I say (and I've been a user and contributor for many years!). Can you point to something in the Autoconf Archive documentation that suggests this is the intended way to use it?

Is it not enought that the Autoconf Archive package is designed to install its macros in /usr/share/aclocal, mandates the syntax of one macro per file where the file is named like the macro (which is what aclocal requires), and that the function of aclocal is exacly that of retrieving the macros necessary for generating a configure script?

This then suggests that it's not a "difference" from not-autotools; rather, Autoconf Archive has a feature that not-autotools lacks, namely that it can be used in an additional way.

A project that supports such a feature makes a choice that has consequences for its own evolution from my point of view.

Sorry if this seems rather pedantic, but I think it's important: it suggests, as I say, that the two projects at the very least can be used in pretty much exactly the same way, without any problem. This is a good thing: it means that a developer who is familiar with not-autotools can immediately use autoconf-archive in the same way, and also that there is a single technique by which both can be combined.

Yes, they can be used in the same way (by manually copying and pasting the macros in both cases). But deciding to support or not automatic macro import with aclocal has repercussions on how the macros evolve (not repercussions on the final user).

from not-autotools.

Is it not enought that the Autoconf Archive package is designed to install its macros in /usr/share/aclocal, mandates the syntax of one macro per file where the file is named like the macro (which is what aclocal requires), and that the function of aclocal is exacly that of retrieving the macros necessary for generating a configure script?

As I said, the documentation says nothing about running make install. The part of the documentation that I quoted says:

[The ]repository can be cloned anonymously, which is probably the most convenient way to access the Archive.

I read this as suggesting that you clone the archive, then copy the macros you need. There is no INSTALL file in the project.

A project that supports such a feature makes a choice that has consequences for its own evolution from my point of view.

As far as I can see, the only consequence you have mentioned is a need for backwards compatibility. But, I have not worried overmuch about making my contributions to Autoconf Archive backwards compatible, as when I introduce an incompatibility that only affects users who want or need to update to a later version of a given macro (which, I have assumed, will only happen at a moment of their choice, because the macros will be copied as source into their project). So, it is not clear to me that the maintainers of Autoconf Archive believe that it is necessary to keep backwards compatibility.

from not-autotools.

the documentation says nothing about running make install

The Autoconf Archive ships a configure.ac and a Makefile.am files. Someone interested in the archive should know what these files are.

There is no INSTALL file in the project.

The INSTALL file magically appears after you launch autoreconf -i.

As far as I can see, the only consequence you have mentioned is a need for backwards compatibility.

More than the need, the freedom from, in the case of the Not Autotools project.

I have not worried overmuch about making my contributions to Autoconf Archive backwards compatible, as when I introduce an incompatibility that only affects users who want or need to update to a later version of a given macro (which, I have assumed, will only happen at a moment of their choice, because the macros will be copied as source into their project).

You assume that since you did not know that Autoconf Archive was an actual package and other packages can depend on it (development-wise) all other developers think the same.

If you look at the “Required By” section of the autoconf-archive package distributed by Arch you will notice that the following packages depend on it in order to be compiled:

gnome-builder, gnome-common, abiword, amsynth, dbus, dbus-python, deepin-metacity, exempi, gnome-applets, gnome-flashback, gnome-latex, gnome-online-miners, gnome-panel, gnote, gnumeric, goffice, gsound, gspell, gtksourceview3, gupnp-dlna, jami-daemon, jp2a, lib32-dbus, lib32-libthai, lib32-polkit, libblockdev, libblockdev (testing), libgee, libgphoto2, libgsf, libimobiledevice, libmm-glib, libplist, libqrtr-glib, libzapojit, metalog, modemmanager, mpfr, pcsclite, pluma, polkit, powertop, profanity, sane, scrot, thermald, ukui-media, ukui-menus, vala, workrave, xdg-dbus-proxy, yelp, zenity

(the list is probably inaccurate, as some of these packages switched to Meson in the meanwhile – but it gives you an idea)

From my experience the normality among package maintainers is actually to let autoreconf copy and paste the AX macros, not to copy and paste them manually.

What I struggle a bit to understand is the main point you want to make in this discussion.

from not-autotools.