[RFC] Deprecating autoconf: Let's do it!

As somebody who's currently hosting LLVM on a platform (OpenVMS Itanium) that has configure but not a working CMake (we're working to fix that but there are some tricky issues), I would appreciate if you didn't scrub the existence of configure from the source or the documentation. Perhaps keep pointers to the older pages and link to them from the downloads pages or something with an "as-is" message? It would at least give somebody a head start if they didn't have CMake. Even telling me to yank the script from an older version would be sufficient.

John

I thought that the Itanium back end was removed a few releases ago. Are you just cross-compiling from Itanium to something else?

David

Correct. We're building cross-compilers hosted on OpenVMS Itanium for a
future OpenVMS x86-64 target. By the time we'll be ready to bootstrap to
native compilers, we'll surely have a CMake in place. I was just thinking
for others like me in the future who might be considering hosting on
non-traditional platforms.

John

As somebody who's currently hosting LLVM on a platform (OpenVMS Itanium) that has configure but not a working CMake (we're working to fix that but there are some tricky issues), I would appreciate if you didn't scrub the existence of configure from the source or the documentation.

Are you proposing that we keep the makefiles? I think we specifically want to get rid of those because it doesn’t make sense to have them around if they aren’t expected to work. I don’t think we will do a concerted scrub of all makefile-related code, but I do expect we’ll remove the configure script and all the makefiles themselves.

We could keep the autoconf documentation around for a release or two with a big “warning” at the top saying the autoconf system is removed in 3.9 and later.

Do you think that is sufficient?

-Chris

Keeping the documentation with large warnings is sufficient. It would at least let somebody then grab an older version's makefiles if they are so inclined/interested. I have no problem with you yanking the files, just the fact that older versions did have configure/makefiles. I only spoke up when I saw the suggestion for removing the online documentation.

John

Keeping the documentation with large warnings is sufficient. It
would at least let somebody then grab an older version's makefiles if
they are so inclined/interested. I have no problem with you yanking
the files, just the fact that older versions did have
configure/makefiles. I only spoke up when I saw the suggestion for
removing the online documentation.

ISTM that this would be "solved" by making old versions of the docs available on the website. I'd rather we avoid documenting features we don't have (even given such a large warning at the top).

Jon

+1.

We already keep the old versions on the website AFAIK, for example: http://llvm.org/releases/3.6.0/docs/index.html

What we may do is changing the sentence in the “Getting Started” page ( http://llvm.org/docs/GettingStarted.html ) from:

"The usual build uses CMake. If you would rather use autotools, see Building LLVM with auto tools.”

to

"The only supported way to build LLVM is using CMake. Releases up to 3.8 were also providing an alternative with the autotools.”

Best,

That would be fine with me. I just don't want some new visitor to come along and see "CMake only" and get discouraged and leave.

That would be fine with me. I just don't want some new visitor to
come along and see "CMake only" and get discouraged and leave.

Well, it is going to be "CMake only". Anyone who depends on autotools is going to be stuck on whatever the last revision is that we shipped with it. And I really don't see it being feasible for someone to port the end-of-life'd autotools build from 3.8 to 3.9 (for example), as we have a hard enough time keeping them in sync when both are in-tree. Also, I sincerely doubt anyone would be motivated enough to pull that off: It's a big project, and I just don't see the ROI in it.

If there's some feature that this hypothetical user needs, which is solved by the autotools build, but isn't handled by CMake... we need to hear about that *now*.

Jon

I think Debian/Ubuntu package builder still uses autoconf. How will the change influence it?

Pawel

I think Debian/Ubuntu package builder still uses autoconf. How will the
change influence it?

Switching that over to CMake should be part of https://llvm.org/bugs/show_bug.cgi?id=15732 if it is not already.

Jon

I agree. That's why I suggested a one-liner in the docs to say if you want autotool-based build, you have to go to an older version. Nothing more is needed.