llvm dev - Nov 2015 - [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

------------------------------

Message: 8
Date: Fri, 06 Nov 2015 09:56:42 -0800
From: Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org>
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [llvm-dev] [RFC] Deprecating autoconf: Let's do it!
Message-ID: <4D17078D-A8AA-446F-8FFB-5988583628CB at apple.com>
Content-Type: text/plain; charset="utf-8"

Hi LLVMDev,

Since my last update we’ve landed patches for these issues:
* Bug 14200 - -fno-rtti not in cxxflags given by llvm-config
* Bug 23746 - test-suite lacks CMake support
* Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not compatible
with ldconfig

On my last thread Jonathan Roelofs pointed out that there is a workaround for
Bug 21568 (Cannot add rpath), so I’m making it non-blocking. Which leaves only
Bug 23947, which I’m also going to move that to non-blocking because it only
applies to building LLVM on MIPS64 hardware.

With those changes we have no issues left blocking deprecating autoconf. There
are still some issues we should track and follow through on, but I think all
major uses are covered and we can make CMake the only officially supported way
to build LLVM.

My proposal at this point is that we should officially deprecate autoconf, and I
would like to follow this process for removing it:

(1) Add a note to the release notes for 3.8, and a big warning at the end of the
configure script telling people to use CMake
(2) Support autoconf with bug fixes only, no new features for 3.8
(3) After the 3.8 branch remove all the makefiles and have the configure script
log a message to use CMake
(4) After the 3.9 branch remove the configure script completely

I’ve attached a patch that handles the first step. Please let me know if this
sounds like a reasonable path for the community.

Also, a big “Thank You” to everyone who has contributed patches, reviewed
patches, and helped out with this work over the last year. It has been a long
road, but the end is in sight!

Thanks,
-Chris

On 9 Nov 2015, at 08:49, John Reagan via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> As somebody who's currently hosting LLVM on a platform (OpenVMS
Itanium) that has configure but not a working CMake
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

-----Original Message-----
From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David
Chisnall
Sent: Monday, November 09, 2015 12:01 PM
To: John Reagan
Cc: llvm-dev at lists.llvm.org; llvm-dev-request at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] Deprecating autoconf: Let's do it!

On 9 Nov 2015, at 08:49, John Reagan via llvm-dev <llvm-dev at
lists.llvm.org>
wrote:
> 
> As somebody who's currently hosting LLVM on a platform (OpenVMS
Itanium)
that has configure but not a working CMake

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

David

> On Nov 9, 2015, at 8:49 AM, John Reagan via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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
> 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
> 
> ------------------------------
> 
> Message: 8
> Date: Fri, 06 Nov 2015 09:56:42 -0800
> From: Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: [llvm-dev] [RFC] Deprecating autoconf: Let's do it!
> Message-ID: <4D17078D-A8AA-446F-8FFB-5988583628CB at apple.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi LLVMDev,
> 
> Since my last update we’ve landed patches for these issues:
> * Bug 14200 - -fno-rtti not in cxxflags given by llvm-config
> * Bug 23746 - test-suite lacks CMake support
> * Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not
compatible with ldconfig
> 
> On my last thread Jonathan Roelofs pointed out that there is a workaround
for Bug 21568 (Cannot add rpath), so I’m making it non-blocking. Which leaves
only Bug 23947, which I’m also going to move that to non-blocking because it
only applies to building LLVM on MIPS64 hardware.
> 
> With those changes we have no issues left blocking deprecating autoconf.
There are still some issues we should track and follow through on, but I think
all major uses are covered and we can make CMake the only officially supported
way to build LLVM.
> 
> My proposal at this point is that we should officially deprecate autoconf,
and I would like to follow this process for removing it:
> 
> (1) Add a note to the release notes for 3.8, and a big warning at the end
of the configure script telling people to use CMake
> (2) Support autoconf with bug fixes only, no new features for 3.8
> (3) After the 3.8 branch remove all the makefiles and have the configure
script log a message to use CMake
> (4) After the 3.9 branch remove the configure script completely
> 
> I’ve attached a patch that handles the first step. Please let me know if
this sounds like a reasonable path for the community.
> 
> Also, a big “Thank You” to everyone who has contributed patches, reviewed
patches, and helped out with this work over the last year. It has been a long
road, but the end is in sight!
> 
> Thanks,
> -Chris
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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

-----Original Message-----
From: cbieneman at apple.com [mailto:cbieneman at apple.com] On Behalf Of Chris
Bieneman
Sent: Monday, November 09, 2015 5:43 PM
To: John Reagan
Cc: llvm-dev; llvm-dev-request at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] Deprecating autoconf: Let's do it!

> On Nov 9, 2015, at 8:49 AM, John Reagan via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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
> 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
> 
> ------------------------------
> 
> Message: 8
> Date: Fri, 06 Nov 2015 09:56:42 -0800
> From: Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: [llvm-dev] [RFC] Deprecating autoconf: Let's do it!
> Message-ID: <4D17078D-A8AA-446F-8FFB-5988583628CB at apple.com>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi LLVMDev,
> 
> Since my last update we’ve landed patches for these issues:
> * Bug 14200 - -fno-rtti not in cxxflags given by llvm-config
> * Bug 23746 - test-suite lacks CMake support
> * Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not
compatible with ldconfig
> 
> On my last thread Jonathan Roelofs pointed out that there is a workaround
for Bug 21568 (Cannot add rpath), so I’m making it non-blocking. Which leaves
only Bug 23947, which I’m also going to move that to non-blocking because it
only applies to building LLVM on MIPS64 hardware.
> 
> With those changes we have no issues left blocking deprecating autoconf.
There are still some issues we should track and follow through on, but I think
all major uses are covered and we can make CMake the only officially supported
way to build LLVM.
> 
> My proposal at this point is that we should officially deprecate autoconf,
and I would like to follow this process for removing it:
> 
> (1) Add a note to the release notes for 3.8, and a big warning at the end
of the configure script telling people to use CMake
> (2) Support autoconf with bug fixes only, no new features for 3.8
> (3) After the 3.8 branch remove all the makefiles and have the configure
script log a message to use CMake
> (4) After the 3.9 branch remove the configure script completely
> 
> I’ve attached a patch that handles the first step. Please let me know if
this sounds like a reasonable path for the community.
> 
> Also, a big “Thank You” to everyone who has contributed patches, reviewed
patches, and helped out with this work over the last year. It has been a long
road, but the end is in sight!
> 
> Thanks,
> -Chris
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev