Please say something about relationship to autoconf-archive about not-autotools HOT 10 CLOSED

This issue has been addressed now.

from not-autotools.

Hi Reuben!

You are right in a way. But the problem is that there isn't really a relationship with the Autoconf Archive.

The first point is the focus. The Autoconf Archive aims mostly at solving compiler or dependency problems, my focus instead is that of working on the M4 language to try and render it as less painful as possible in its integration with the shell and the configure script.

The second point is the way the macros are distributed. The Autoconf Archive expects you to install a package that makes the macros automatically available. I instead release macros that need to be copied and pasted, or included directly in the build directory.

The third point is the freedom. I really like to publish what I want when I want, and decide how to categorize it. You can think of this as a laboratory.

I would be happy though if someone published in the Autoconf Archive any of the macros released here. But I already know that I cannot work on the synchronization of two repositories.

I hope you will find something useful in this archive.

--madmurphy

from not-autotools.

Those points are exactly what I'm looking for: as a reader I want to know "what's the goals of this similarly-named project?" You just answered that. Something like that in the README would be great.

Another thing that would help would be some short examples. e.g. I know M4 is painful, but I a) I hardly ever write any in all the many autotools build systems I maintain; and b) autotools already provide macros to make it easier. So a quick demo of what you're doing that's better/different would be very useful.

Good luck with your project!

from not-autotools.

Those points are exactly what I'm looking for: as a reader I want to know "what's the goals of this similarly-named project?" You just answered that. Something like that in the README would be great.

It might not be a bad idea after all. The main reason why I never did that is that this was born as my personal repository of the macros I use or might use. Since I use them, I often revise them and I care that they work properly, but I never really thought of a general direction. I do have opinions though on what the strength and weaknesses of Autotools are (and by the way, I really like the concept of Autotools), so I tend to work on the weaknesses. As soon as I have a bit of time I will expand the README.

Another thing that would help would be some short examples. e.g. I know M4 is painful, but I a) I hardly ever write any in all the many autotools build systems I maintain; and b) autotools already provide macros to make it easier. So a quick demo of what you're doing that's better/different would be very useful.

I was also thinking, since it would not be bad to have a second opinion, how about giving the macros a try and telling me if the documentation is clear enough? All the macros have examples in the comment that precedes them. If you want to see them in action, the libconfini project uses many of these macros massively – they are easy to spot, since their names always have a prefix that start with an "n" (NA_, NC_, NM_, NS_, n4_).

--madmurphy

from not-autotools.

I had a quick look: I see there's quite a lot of documentation, which is good.

My overall view would be a more cautious one, though: mainly, "why should I invest the time I'd need to work out whether this stuff is useful?". An explainer and some examples in the README would be a good potential motivation (or tell me that it's not for me). To take just two examples, my main question about the autoreconf-related stuff is "why would I need that?" and in the C compiler-related stuff, when you say "like AX_FOO, but with improvements" my question is "OK, so why didn't you just improve AX_FOO [which maybe I already use]?".

This project has the advantages and disadvantages of any new project (I, a potential user have to meta-decide whether it's worth my time trying to work out if it's worth my time learning to use it and trying it out), and in this particular case I'm sceptical, because it's an add-on to an established (set of) packages, namely, autotools. (In a way, if it were something shiny and new it'd be an easier sell.)

Of course, you might not care about whether anyone else uses it, which is fine! but at the moment I doubt, as a practised user of autotools, I'd be that interested in learning a new package that promised an incremental improvement to autotools, and far more likely to invest learning time in a newer build system that has more compelling ground-up advantages.

I hope that's not too disheartening! I am sure that I'll continue to use autotools for some time; but I am increasingly looking for alternatives for projects that don't really need it; the biggest reason I stick with it for many projects, BTW, is gnulib.

from not-autotools.

I had a quick look: I see there's quite a lot of documentation, which is good.

I knew that.

My overall view would be a more cautious one, though: mainly, "why should I invest the time I'd need to work out whether this stuff is useful?".

You shouldn't. These macros are born out of necessity. If you never had any problem you should definitely not create new ones.

An explainer and some examples in the README would be a good potential motivation (or tell me that it's not for me).

I agree on that.

To take just two examples, my main question about the autoreconf-related stuff is "why would I need that?"

There are many tasks that can be done during the autoreconf process. Currently these tasks are mainly done by bootstrap scripts, which are blind to M4. But this does not mean that it would be a bad idea to pass these tasks to a native environment. Consider this for example:

n4_define_substrings_as(NR_PROG_VERSION([libtool]),
    [\([0-9]+\)\.\([0-9]+\)],
    [LTVERSION_STR], [LTVERSION_MAJ], [LTVERSION_MIN]
)

m4_if(m4_eval(LTVERSION_MAJ[ < 2 || ]LTVERSION_MIN[ < 4]), [1],
    [m4_fatal([Sorry, your libtool version is too old for this package])])

It is not rare on the other hand to see bootstrap scripts that do things as ugly as this:

(grep "^LT_INIT" $srcdir/configure.ac >/dev/null) && {
  (libtool --version) < /dev/null > /dev/null 2>&1 || {
    echo
    echo "**Error**: You must have \`libtool' installed."
    echo "You can get it from: ftp://ftp.gnu.org/pub/gnu/"
    DIE=1
  }
}

and in the C compiler-related stuff, when you say "like AX_FOO, but with improvements" my question is "OK, so why didn't you just improve AX_FOO [which maybe I already use]?".

In this case the answer is simple: I did not just improve it, I reshaped it by adding new arguments. The Autoconf Archive is used by many persons, and I didn't want to take the responsibility of breaking their configure scripts with a backward-incompatible change. As I said before, I like that this is a very informal repository. If I make a backward-incompatible change it doesn't break anything: as the macros are hard-copied in your package, you will have to update them manually – and at that point you will likely read the new documentation.

in this particular case I'm sceptical, because it's an add-on to an established (set of) packages, namely, autotools. (In a way, if it were something shiny and new it'd be an easier sell.)

The "established (set of) packages" is not all shiny either... I believe it has its weaknesses. But that does not mean it cannot improve...

I am increasingly looking for alternatives for projects that don't really need it

Speaking of Autotools' shininess... By the way that's exactly one of the strength of Autotools: a build system that needs itself only once per release (and only the developers need it). After that moment everything goes to a configure shell script.

I hope this answers to all your doubts.

--madmurphy

from not-autotools.

Thanks for the detailed reply!

There are many tasks that can be done during the autoreconf process. Currently these tasks are mainly done by bootstrap scripts, which are blind to M4. But this does not mean that it would be a bad idea to pass these tasks to a native environment. Consider this for example:

n4_define_substrings_as(NR_PROG_VERSION([libtool]),
    [\([0-9]+\)\.\([0-9]+\)],
    [LTVERSION_STR], [LTVERSION_MAJ], [LTVERSION_MIN]
)

m4_if(m4_eval(LTVERSION_MAJ[ < 2 || ]LTVERSION_MIN[ < 4]), [1],
    [m4_fatal([Sorry, your libtool version is too old for this package])])

I don't understand this: LT_PREREQ exists to check the version of libtool. Why would either your solution or the bootstrap hack you mention be needed?

In this case the answer is simple: I did not just improve it, I reshaped it by adding new arguments. The Autoconf Archive is used by many persons, and I didn't want to take the responsibility of breaking their configure scripts with a backward-incompatible change. As I said before, I like that this is a very informal repository. If I make a backward-incompatible change it doesn't break anything: as the macros are hard-copied in your package, you will have to update them manually – and at that point you will likely read the new documentation.

OK, I guess that's a choice: by putting in the hard work of adapting changes to upstream them, many more users benefit. By not doing so, a smaller number of more energetic users get the chance to benefit from your ideas which otherwise they might not.

The "established (set of) packages" is not all shiny either... I believe it has its weaknesses. But that does not mean it cannot improve...

No, but I think what I'm getting at is that you don't seem to be trying to improve it; you're offering an alternative.

from not-autotools.

I don't understand this: LT_PREREQ exists to check the version of libtool. Why would either your solution or the bootstrap hack you mention be needed?

LT_PREREQ is a perfect example of a macro that starts and terminates its task during autoreconf, it will leave no traces in the configure script (this answers your previous question about what can be done during autoreconf). Of course, when a native macro is available there is no need to launch NR_PROG_VERSION(). But many different programs might be required during autoreconf besides the Autotools suite (or the ones that possess an M4 integration with Autoconf). I just wrote a general-purpose solution for that.

No, but I think what I'm getting at is that you don't seem to be trying to improve it; you're offering an alternative.

How a collection of extensions for a program can possibly be an alternative to that program? If Autotools dies this collections dies too. Maybe my project's name influences your impression, but that name comes only from my habit of marking my custom macros with the NA_ prefix, as a way of reminding myself that “this macro is Not (part of) Autotools”. The Autotools suite can just benefit from collections like this – in the hope that the quality is good enough.

You can think of it as a possible staging laboratory for the Autoconf Archive. Here the macros often change radically, or even disappear, without caring for backward compatibility. This has the advantage of not slowing down its evolution. If something is really good I hope it ends up in the Autoconf Archive somehow. But I cannot be the one that submits it there – in the moment I will do that I know that I will be telling myself “Ok, I am done with this macro, I will not update it anymore”.

--madmurphy

from not-autotools.

You're right, "alternative" is a bad choice of word. I was trying to say that you're offering an extra tool that one has to learn as well, rather than incremental improvements.

I like the idea of a staging lab! Some phrase like that might make a good strapline for this project.

from not-autotools.

You're right, "alternative" is a bad choice of word. I was trying to say that you're offering an extra tool that one has to learn as well, rather than incremental improvements.

I think that copying and pasting a macro lets you see how it is written, and that can give you some insights on how Autotools works. On the other hand Autoconf Archive seems more for who just wants to use what is ready and available, without thinking too much. I think both approaches are needed.

I like the idea of a staging lab! Some phrase like that might make a good strapline for this project.

I might end up copying and pasting this conversation as README :)

--madmurphy

from not-autotools.