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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: deprecate-autoconf.diff
Type: application/octet-stream
Size: 1533 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151106/e45ce663/attachment.obj>

On 6 November 2015 at 17:56, Chris Bieneman via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> My proposal at this point is that we should officially deprecate autoconf,
and I would like to follow this process for removing it:
Hi Chris,

+2 for this!

We have moved every ARM and AArch64 buildbot to CMake, and the 3.7
release was done using CMake. So now, I don't even know if autoconf
works any more. :)

> (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
Sounds like a plan! +1

cheers,
--renato

PS: It's about time I change the documentation... :)
http://llvm.org/docs/HowToBuildOnARM.html

That is awesome! Thank you so much!
On Nov 6, 2015 12:57 PM, "Chris Bieneman via llvm-dev" <
llvm-dev at lists.llvm.org> wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151106/e93eb38b/attachment.html>

Chris,
Thank you for the fantastic work getting this done.  All of the effort is
very much appreciated!

-Mike

On Fri, Nov 6, 2015 at 9:56 AM, Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151106/e6923d89/attachment.html>

Chris,

Thank you for your hard work on this!!!

Anna.
> On Nov 6, 2015, at 9:56 AM, Chris Bieneman via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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
> 
>
<deprecate-autoconf.diff>_______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On Fri, Nov 6, 2015 at 9:56 AM, Chris Bieneman via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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
This sounds excellent!

During the 3.7 release, Dimitry reported that some components didn't
build on FreeBSD with cmake yet. Is that fixed now? I'd like to have
all binaries built with cmake for 3.8.

Cheers,
Hans

Awesome!  Thanks for making this happen!

—Owen
> On Nov 6, 2015, at 9:56 AM, Chris Bieneman via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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
> 
>
<deprecate-autoconf.diff>_______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On Fri, Nov 06, 2015 at 04:17:04PM -0800, Hans Wennborg via llvm-dev
wrote:
> On Fri, Nov 6, 2015 at 9:56 AM, Chris Bieneman via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > 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
> 
> This sounds excellent!
> 
> During the 3.7 release, Dimitry reported that some components didn't
> build on FreeBSD with cmake yet. Is that fixed now? I'd like to have
> all binaries built with cmake for 3.8.
I think we're OK here.  I've got llvm, clang, clang-tools-extra,
compiler-rt, lld, lldb, and openmp building from cmake in the FreeBSD
ports collection.

-- Brooks

Also add a deprecation warning to the top of
docs/BuildingLLVMWithAutotools.rst ( with `.. warning::`, which will make a
big fancy box), and remove mention of autotools from docs/GettingStarted.rst

On Fri, Nov 6, 2015 at 9:56 AM, Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151106/8d58a5a5/attachment.html>

This is awesome!

On Fri, Nov 6, 2015 at 9:56 AM, Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151106/604c1f0c/attachment-0001.html>

We've already chatted do you know I'm in favor, but here's an
explicit +1 :)

Thanks!

-eric

On Fri, Nov 6, 2015, 9:57 AM Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151107/cd761d6f/attachment.html>

Just wanted to give an explicit agreement with your plan for deprecating
autoconf. Looking forward to it. Thanks for the crazy amount of work this
has required.

On Fri, Nov 6, 2015 at 12:56 PM Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151109/f76b85e8/attachment.html>

> 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.
+1 that this should be non-blocking and to the deprecation of autoconf in
general. Just for the sake of correctness: PR23947 isn't exactly about
building on MIPS64 hardware. It's really about building for a non-default
multilib (in this case the 64-bit multilibs of a generally 32-bit linux
distribution).

We still have several buildbots on autoconf at the moment but I'll sort that
out.

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris
Bieneman via llvm-dev
Sent: 06 November 2015 17:57
To: llvm-dev
Subject: [llvm-dev] [RFC] Deprecating autoconf: Let's do it!

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<mailto: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/6ceff510/attachment-0001.html>