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

Paweł Bylica via llvm-dev llvm-dev at lists.llvm.org
Tue Nov 10 07:23:30 PST 2015


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

Pawel

On Tue, Nov 10, 2015, 15:11 Jonathan Roelofs via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On 11/9/15 5:49 PM, John Reagan wrote:
> > 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
>
> >
> > -----Original Message----- From: mehdi.amini at apple.com
> > [mailto:mehdi.amini at apple.com] Sent: Monday, November 09, 2015 6:30
> > PM To: Jonathan Roelofs Cc: John Reagan; Chris Bieneman; 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 3:21 PM, Jonathan Roelofs via llvm-dev
> >> <llvm-dev at lists.llvm.org> wrote:
> >>
> >>
> >>
> >> On 11/9/15 4:02 PM, John Reagan via llvm-dev wrote:
> >>> 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).
> >
> >
> > +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,
> >
> > — Mehdi
> >
> >
> >
> >
> >
> >>
> >>
> >> Jon
> >>
> >>>
> >>> 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
> >>>
> >>>
> >>>
> >>> _______________________________________________ LLVM Developers
> >>> mailing list llvm-dev at lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>>
> >>
> >> -- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor
> >> Embedded
> >>
> >> -- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor
> >> Embedded _______________________________________________ LLVM
> >> Developers mailing list llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
> >
>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151110/a6bef594/attachment.html>


More information about the llvm-dev mailing list