Eli Bendersky
2014-Nov-03 17:51 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
On Mon, Nov 3, 2014 at 9:26 AM, Tom Stellard <tom at stellard.net> wrote:> On Fri, Oct 31, 2014 at 04:31:47PM -0700, Bob Wilson wrote: > > > > > On Oct 31, 2014, at 4:19 PM, Eric Christopher <echristo at gmail.com> > wrote: > > > > > > > > > > > > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <tom at stellard.net > <mailto:tom at stellard.net>> wrote: > > > Hi, > > > > > > I would like to propose deprecating the autoconf build system at some > > > point in the future. Maintaining two build systems is a hassle not > > > only for this project, but also for other projects that use LLVM > > > and have to deal with the slight differences in output between the two > > > build systems. > > > > > > It seems like most people are using CMake at this point, so my > questions > > > to the community are: > > > > > > - Is there any technical reason why the remaining autoconf users can't > switch > > > to CMake? > > > > > > > > > I think Bob was the lead on keeping the autoconf system last year when > this came up, there is a PR somewhere in the system about the blocking > things that need to work in cmake to get it to happen. I don't know where > we are on that list or what features people still need. > > > > I’ve come around to the point of accepting the inevitability of moving > to cmake, but I think there’s quite a bit of work to be done to get > everything to work. The compiler-rt build in particular is problematic. > > > > > > > > Personally I still use the autoconf system, but am willing to remove > it if we can get to a single system, but all of the requirements need to be > handled first. > > > > > > -eric > > > > > > For example, I personally use automake, and the only reason I don't > > > use CMake is because it doesn't produce a single shared object > > > (e.g. libLLVM-3.6.0svn.so <http://libllvm-3.6.0svn.so/>). > > > > > > - What is a reasonable timeframe to allow the remaining autoconf users > > > a chance to migrate to CMake? > > > > I don’t know how to answer that. Someone will need to do the work to > first identify all the problems and then to get them fixed. > > > > Converting everything to cmake will take quite a lot of work. In > comparison, the minor hassle of keeping the makefiles working for a bit > longer seems pretty insignificant. > > The main problem is testing. It doubles the testing load to have two > build systems, because we need to make sure both build systems work > on all platforms. > >+1 to this. The situation I frequently find myself in is - doing development using CMake + ninja, and then when I need to actually commit to SVN, I need to build & test with the makefile as well because the builds are slightly different, of occasionally make builds fail where CMake + ninja suceeds. And rebuilding all of LLVM + Clang with the makefile build is *slow*, even on a fast machine. Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141103/253a8b36/attachment.html>
Bob Wilson
2014-Nov-03 18:00 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
> On Nov 3, 2014, at 9:51 AM, Eli Bendersky <eliben at google.com> wrote: > > > > On Mon, Nov 3, 2014 at 9:26 AM, Tom Stellard <tom at stellard.net <mailto:tom at stellard.net>> wrote: > On Fri, Oct 31, 2014 at 04:31:47PM -0700, Bob Wilson wrote: > > > > > On Oct 31, 2014, at 4:19 PM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote: > > > > > > > > > > > > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <tom at stellard.net <mailto:tom at stellard.net> <mailto:tom at stellard.net <mailto:tom at stellard.net>>> wrote: > > > Hi, > > > > > > I would like to propose deprecating the autoconf build system at some > > > point in the future. Maintaining two build systems is a hassle not > > > only for this project, but also for other projects that use LLVM > > > and have to deal with the slight differences in output between the two > > > build systems. > > > > > > It seems like most people are using CMake at this point, so my questions > > > to the community are: > > > > > > - Is there any technical reason why the remaining autoconf users can't switch > > > to CMake? > > > > > > > > > I think Bob was the lead on keeping the autoconf system last year when this came up, there is a PR somewhere in the system about the blocking things that need to work in cmake to get it to happen. I don't know where we are on that list or what features people still need. > > > > I’ve come around to the point of accepting the inevitability of moving to cmake, but I think there’s quite a bit of work to be done to get everything to work. The compiler-rt build in particular is problematic. > > > > > > > > Personally I still use the autoconf system, but am willing to remove it if we can get to a single system, but all of the requirements need to be handled first. > > > > > > -eric > > > > > > For example, I personally use automake, and the only reason I don't > > > use CMake is because it doesn't produce a single shared object > > > (e.g. libLLVM-3.6.0svn.so <http://libllvm-3.6.0svn.so/> <http://libllvm-3.6.0svn.so/ <http://libllvm-3.6.0svn.so/>>). > > > > > > - What is a reasonable timeframe to allow the remaining autoconf users > > > a chance to migrate to CMake? > > > > I don’t know how to answer that. Someone will need to do the work to first identify all the problems and then to get them fixed. > > > > Converting everything to cmake will take quite a lot of work. In comparison, the minor hassle of keeping the makefiles working for a bit longer seems pretty insignificant. > > The main problem is testing. It doubles the testing load to have two > build systems, because we need to make sure both build systems work > on all platforms. > > > +1 to this. > > The situation I frequently find myself in is - doing development using CMake + ninja, and then when I need to actually commit to SVN, I need to build & test with the makefile as well because the builds are slightly different, of occasionally make builds fail where CMake + ninja suceeds. And rebuilding all of LLVM + Clang with the makefile build is *slow*, even on a fast machine.So wouldn’t the first step be to fix any cases where the builds are slightly different? I think it would make sense to scale back on testing with make, but if you’re seeing cases where the builds differ, then fixing those differences will be a prerequisite to dropping make. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141103/89d0bacf/attachment.html>
Eli Bendersky
2014-Nov-03 18:23 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
On Mon, Nov 3, 2014 at 10:00 AM, Bob Wilson <bob.wilson at apple.com> wrote:> > On Nov 3, 2014, at 9:51 AM, Eli Bendersky <eliben at google.com> wrote: > > > > On Mon, Nov 3, 2014 at 9:26 AM, Tom Stellard <tom at stellard.net> wrote: > >> On Fri, Oct 31, 2014 at 04:31:47PM -0700, Bob Wilson wrote: >> > >> > > On Oct 31, 2014, at 4:19 PM, Eric Christopher <echristo at gmail.com> >> wrote: >> > > >> > > >> > > >> > > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <tom at stellard.net >> <mailto:tom at stellard.net>> wrote: >> > > Hi, >> > > >> > > I would like to propose deprecating the autoconf build system at some >> > > point in the future. Maintaining two build systems is a hassle not >> > > only for this project, but also for other projects that use LLVM >> > > and have to deal with the slight differences in output between the two >> > > build systems. >> > > >> > > It seems like most people are using CMake at this point, so my >> questions >> > > to the community are: >> > > >> > > - Is there any technical reason why the remaining autoconf users >> can't switch >> > > to CMake? >> > > >> > > >> > > I think Bob was the lead on keeping the autoconf system last year >> when this came up, there is a PR somewhere in the system about the blocking >> things that need to work in cmake to get it to happen. I don't know where >> we are on that list or what features people still need. >> > >> > I’ve come around to the point of accepting the inevitability of moving >> to cmake, but I think there’s quite a bit of work to be done to get >> everything to work. The compiler-rt build in particular is problematic. >> > >> > > >> > > Personally I still use the autoconf system, but am willing to remove >> it if we can get to a single system, but all of the requirements need to be >> handled first. >> > > >> > > -eric >> > > >> > > For example, I personally use automake, and the only reason I don't >> > > use CMake is because it doesn't produce a single shared object >> > > (e.g. libLLVM-3.6.0svn.so <http://libllvm-3.6.0svn.so/> < >> http://libllvm-3.6.0svn.so/>). >> > > >> > > - What is a reasonable timeframe to allow the remaining autoconf users >> > > a chance to migrate to CMake? >> > >> > I don’t know how to answer that. Someone will need to do the work to >> first identify all the problems and then to get them fixed. >> > >> > Converting everything to cmake will take quite a lot of work. In >> comparison, the minor hassle of keeping the makefiles working for a bit >> longer seems pretty insignificant. >> >> The main problem is testing. It doubles the testing load to have two >> build systems, because we need to make sure both build systems work >> on all platforms. >> >> > +1 to this. > > The situation I frequently find myself in is - doing development using > CMake + ninja, and then when I need to actually commit to SVN, I need to > build & test with the makefile as well because the builds are slightly > different, of occasionally make builds fail where CMake + ninja suceeds. > And rebuilding all of LLVM + Clang with the makefile build is *slow*, even > on a fast machine. > > > So wouldn’t the first step be to fix any cases where the builds are > slightly different? > > I think it would make sense to scale back on testing with make, but if > you’re seeing cases where the builds differ, then fixing those differences > will be a prerequisite to dropping make. >That's true. AFAIR, the differences were due to different flags (or at least order of flags) passed to the compiler in the two cases. I'll report such cases concretely when I run into it again. Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141103/399e9ddc/attachment.html>
Matt Arsenault
2014-Nov-04 18:56 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
On 11/03/2014 09:51 AM, Eli Bendersky wrote:> > > On Mon, Nov 3, 2014 at 9:26 AM, Tom Stellard <tom at stellard.net > <mailto:tom at stellard.net>> wrote: > > On Fri, Oct 31, 2014 at 04:31:47PM -0700, Bob Wilson wrote: > > > > > On Oct 31, 2014, at 4:19 PM, Eric Christopher > <echristo at gmail.com <mailto:echristo at gmail.com>> wrote: > > > > > > > > > > > > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <tom at stellard.net > <mailto:tom at stellard.net> <mailto:tom at stellard.net > <mailto:tom at stellard.net>>> wrote: > > > Hi, > > > > > > I would like to propose deprecating the autoconf build system > at some > > > point in the future. Maintaining two build systems is a > hassle not > > > only for this project, but also for other projects that use LLVM > > > and have to deal with the slight differences in output between > the two > > > build systems. > > > > > > It seems like most people are using CMake at this point, so my > questions > > > to the community are: > > > > > > - Is there any technical reason why the remaining autoconf > users can't switch > > > to CMake? > > > > > > > > > I think Bob was the lead on keeping the autoconf system last > year when this came up, there is a PR somewhere in the system > about the blocking things that need to work in cmake to get it to > happen. I don't know where we are on that list or what features > people still need. > > > > I’ve come around to the point of accepting the inevitability of > moving to cmake, but I think there’s quite a bit of work to be > done to get everything to work. The compiler-rt build in > particular is problematic. > > > > > > > > Personally I still use the autoconf system, but am willing to > remove it if we can get to a single system, but all of the > requirements need to be handled first. > > > > > > -eric > > > > > > For example, I personally use automake, and the only reason I > don't > > > use CMake is because it doesn't produce a single shared object > > > (e.g. libLLVM-3.6.0svn.so <http://libLLVM-3.6.0svn.so> > <http://libllvm-3.6.0svn.so/>). > > > > > > - What is a reasonable timeframe to allow the remaining > autoconf users > > > a chance to migrate to CMake? > > > > I don’t know how to answer that. Someone will need to do the > work to first identify all the problems and then to get them fixed. > > > > Converting everything to cmake will take quite a lot of work. In > comparison, the minor hassle of keeping the makefiles working for > a bit longer seems pretty insignificant. > > The main problem is testing. It doubles the testing load to have two > build systems, because we need to make sure both build systems work > on all platforms. > > > +1 to this. > > The situation I frequently find myself in is - doing development using > CMake + ninja, and then when I need to actually commit to SVN, I need > to build & test with the makefile as well because the builds are > slightly different, of occasionally make builds fail where CMake + > ninja suceeds. And rebuilding all of LLVM + Clang with the makefile > build is *slow*, even on a fast machine. > > Eli >This is extra burdensome because LLVM requires an ancient version of autotools. You need to track down the old versions and install them to regenerate the makefiles, which is a lot of unnecessary work. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/4add7f97/attachment.html>
Eric Christopher
2014-Nov-04 19:08 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
On Tue Nov 04 2014 at 11:01:54 AM Matt Arsenault <Matthew.Arsenault at amd.com> wrote:> On 11/03/2014 09:51 AM, Eli Bendersky wrote: > > > > On Mon, Nov 3, 2014 at 9:26 AM, Tom Stellard <tom at stellard.net> wrote: > >> On Fri, Oct 31, 2014 at 04:31:47PM -0700, Bob Wilson wrote: >> > >> > > On Oct 31, 2014, at 4:19 PM, Eric Christopher <echristo at gmail.com> >> wrote: >> > > >> > > >> > > >> > > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <tom at stellard.net >> <mailto:tom at stellard.net>> wrote: >> > > Hi, >> > > >> > > I would like to propose deprecating the autoconf build system at some >> > > point in the future. Maintaining two build systems is a hassle not >> > > only for this project, but also for other projects that use LLVM >> > > and have to deal with the slight differences in output between the two >> > > build systems. >> > > >> > > It seems like most people are using CMake at this point, so my >> questions >> > > to the community are: >> > > >> > > - Is there any technical reason why the remaining autoconf users >> can't switch >> > > to CMake? >> > > >> > > >> > > I think Bob was the lead on keeping the autoconf system last year >> when this came up, there is a PR somewhere in the system about the blocking >> things that need to work in cmake to get it to happen. I don't know where >> we are on that list or what features people still need. >> > >> > I’ve come around to the point of accepting the inevitability of moving >> to cmake, but I think there’s quite a bit of work to be done to get >> everything to work. The compiler-rt build in particular is problematic. >> > >> > > >> > > Personally I still use the autoconf system, but am willing to remove >> it if we can get to a single system, but all of the requirements need to be >> handled first. >> > > >> > > -eric >> > > >> > > For example, I personally use automake, and the only reason I don't >> > > use CMake is because it doesn't produce a single shared object >> > > (e.g. libLLVM-3.6.0svn.so <http://libllvm-3.6.0svn.so/>). >> > > >> > > - What is a reasonable timeframe to allow the remaining autoconf users >> > > a chance to migrate to CMake? >> > >> > I don’t know how to answer that. Someone will need to do the work to >> first identify all the problems and then to get them fixed. >> > >> > Converting everything to cmake will take quite a lot of work. In >> comparison, the minor hassle of keeping the makefiles working for a bit >> longer seems pretty insignificant. >> >> The main problem is testing. It doubles the testing load to have two >> build systems, because we need to make sure both build systems work >> on all platforms. >> >> > +1 to this. > > The situation I frequently find myself in is - doing development using > CMake + ninja, and then when I need to actually commit to SVN, I need to > build & test with the makefile as well because the builds are slightly > different, of occasionally make builds fail where CMake + ninja suceeds. > And rebuilding all of LLVM + Clang with the makefile build is *slow*, even > on a fast machine. > > Eli > > > This is extra burdensome because LLVM requires an ancient version of > autotools. You need to track down the old versions and install them to > regenerate the makefiles, which is a lot of unnecessary work. >I have a script that does this. It takes 3 minutes including install time. Also, I do this for many people so it's not burdensome. -eric> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/634732dd/attachment.html>