Chris Bieneman
2014-Nov-04 18:56 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
Sorry I’m a little late to this thread. There has been some discussion about using CMake to generate shared libraries. Since I’ve done some patches in this area recently I thought I’d take a minute to explain the current state of things. Historically LLVM’s CMake build system has been able to produce shared libraries for each of the llvm static libraries. My patch (r220490) added the llvm-shlib tool to the CMake build system. You can now set LLVM_BUILD_LLVM_DYLIB=On on the CMake command line to generate a single libLLVM.dylib with a default set of LLVM libraries included. Tom, I’m really curious if this is close to meeting your needs. I’m guessing we probably need to add the version number to the library. Anything else? James, you commented that you like multiple so files because it allows you to pick and choose which bits you need. With the new llvm-shlib in CMake you can specify which components you want included in the LLVM dylib by setting LLVM_DYLIB_COMPONENTS to a semicolon delimited list of LLVM components. I looked at compiler-rt a few months back so I might be able to shed a little bit of light into what needs to be fixed in compiler-rt for us. The complication for compiler-rt is that you need to build it for your targets rather than your host, so it immediately becomes a cross-compilation problem. The current CMake configs for compiler-rt actually don’t treat it as cross-compilation, they just try to override the build settings. I think the correct solution (at least for Darwin) is going to be to refactor compiler-rt to actually be cross-configured for each architecture. My CMake-foo is nowhere near master-level, so I’m a bit fuzzy on some of the details, but CMake has this notion of exported targets, and I think compiler-rt should really just generate a bunch of exported targets that get slurped into a host llvm/clang CMake build. I know this is getting a bit off topic, but if anyone wants to talk more about this feel free to email me or grab me on IRC. -Chris> On Nov 3, 2014, at 10:29 AM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Mon Nov 03 2014 at 9:36:45 AM Tom Stellard <tom at stellard.net <mailto:tom at stellard.net>> wrote: > On Fri, Oct 31, 2014 at 11:19:22PM +0000, Eric Christopher 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. > > Was this the PR: http://www.llvm.org/bugs/show_bug.cgi?id=15732 <http://www.llvm.org/bugs/show_bug.cgi?id=15732> ? > > > Looks like it yes. > > -eric > > -Tom > > > > > 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? > > > > > > Thanks, > > > Tom > > > _______________________________________________ > > > LLVM Developers mailing list > > > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> > > > > _______________________________________________ > 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/f5e5ff3f/attachment.html>
Alexey Samsonov
2014-Nov-07 02:09 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
On Tue, Nov 4, 2014 at 10:56 AM, Chris Bieneman <beanz at apple.com> wrote:> Sorry I’m a little late to this thread. > > There has been some discussion about using CMake to generate shared > libraries. Since I’ve done some patches in this area recently I thought I’d > take a minute to explain the current state of things. > > Historically LLVM’s CMake build system has been able to produce shared > libraries for each of the llvm static libraries. My patch (r220490) added > the llvm-shlib tool to the CMake build system. You can now set > LLVM_BUILD_LLVM_DYLIB=On on the CMake command line to generate a single > libLLVM.dylib with a default set of LLVM libraries included. > > Tom, I’m really curious if this is close to meeting your needs. I’m > guessing we probably need to add the version number to the library. > Anything else? > > James, you commented that you like multiple so files because it allows you > to pick and choose which bits you need. With the new llvm-shlib in CMake > you can specify which components you want included in the LLVM dylib by > setting LLVM_DYLIB_COMPONENTS to a semicolon delimited list of LLVM > components. > > I looked at compiler-rt a few months back so I might be able to shed a > little bit of light into what needs to be fixed in compiler-rt for us. The > complication for compiler-rt is that you need to build it for your targets > rather than your host, so it immediately becomes a cross-compilation > problem. The current CMake configs for compiler-rt actually don’t treat it > as cross-compilation, they just try to override the build settings. I think > the correct solution (at least for Darwin) is going to be to refactor > compiler-rt to actually be cross-configured for each architecture. >That is correct. I think the only reasonable way to improve CMake build system for compiler-rt would be to: 1) have a simple build rules in compiler-rt itself, w/o any architecture/target detection, and 2) make Clang create multiple compiler-rt builds, one for each architecture we're targeting, and make all these builds use just-built Clang as a host compiler. There are initial attempts to achieve this, checked in tools/clang/runtime/CMakeLists.txt, but I never got to finishing and enforcing this, even on Linux. I hope to find a time and work on it soon, but feel free to reach out to me if you want to give it a shot.> > My CMake-foo is nowhere near master-level, so I’m a bit fuzzy on some of > the details, but CMake has this notion of exported targets, and I think > compiler-rt should really just generate a bunch of exported targets that > get slurped into a host llvm/clang CMake build. I know this is getting a > bit off topic, but if anyone wants to talk more about this feel free to > email me or grab me on IRC. > > -Chris > > On Nov 3, 2014, at 10:29 AM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Mon Nov 03 2014 at 9:36:45 AM Tom Stellard <tom at stellard.net> wrote: > >> On Fri, Oct 31, 2014 at 11:19:22PM +0000, Eric Christopher wrote: >> > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <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. >> >> Was this the PR: http://www.llvm.org/bugs/show_bug.cgi?id=15732 ? >> >> > Looks like it yes. > > -eric > > >> -Tom >> >> > >> > 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? >> > > >> > > Thanks, >> > > Tom >> > > _______________________________________________ >> > > LLVM Developers mailing list >> > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- Alexey Samsonov vonosmas at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141106/5146c34a/attachment.html>
Tom Stellard
2014-Nov-13 15:38 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
On Thu, Nov 06, 2014 at 06:09:06PM -0800, Alexey Samsonov wrote:> On Tue, Nov 4, 2014 at 10:56 AM, Chris Bieneman <beanz at apple.com> wrote: > > > Sorry I’m a little late to this thread. > > > > There has been some discussion about using CMake to generate shared > > libraries. Since I’ve done some patches in this area recently I thought I’d > > take a minute to explain the current state of things. > > > > Historically LLVM’s CMake build system has been able to produce shared > > libraries for each of the llvm static libraries. My patch (r220490) added > > the llvm-shlib tool to the CMake build system. You can now set > > LLVM_BUILD_LLVM_DYLIB=On on the CMake command line to generate a single > > libLLVM.dylib with a default set of LLVM libraries included. > > > > Tom, I’m really curious if this is close to meeting your needs. I’m > > guessing we probably need to add the version number to the library. > > Anything else? > > > > James, you commented that you like multiple so files because it allows you > > to pick and choose which bits you need. With the new llvm-shlib in CMake > > you can specify which components you want included in the LLVM dylib by > > setting LLVM_DYLIB_COMPONENTS to a semicolon delimited list of LLVM > > components. > > > > I looked at compiler-rt a few months back so I might be able to shed a > > little bit of light into what needs to be fixed in compiler-rt for us. The > > complication for compiler-rt is that you need to build it for your targets > > rather than your host, so it immediately becomes a cross-compilation > > problem. The current CMake configs for compiler-rt actually don’t treat it > > as cross-compilation, they just try to override the build settings. I think > > the correct solution (at least for Darwin) is going to be to refactor > > compiler-rt to actually be cross-configured for each architecture. > > > > That is correct. I think the only reasonable way to improve CMake build > system for compiler-rt would be to: > 1) have a simple build rules in compiler-rt itself, w/o any > architecture/target detection, and > 2) make Clang create multiple compiler-rt builds, one for each architecture > we're targeting, and make all these builds use just-built Clang as a host > compiler. > There are initial attempts to achieve this, checked in > tools/clang/runtime/CMakeLists.txt, but I never got to finishing and > enforcing this, even on Linux. I hope to find a time and work on it > soon, but feel free to reach out to me if you want to give it a shot. > >Hi, I've filed a bug specifically for converting make/platform/clang_darwin.mk to CMake, but it sounds like we may need a larger bug for converting all of compiler-rt. If you or Chris want to create this larger bug and add some of your thoughts on how to implement it, that would be very helpful. Thanks, Tom> > > > My CMake-foo is nowhere near master-level, so I’m a bit fuzzy on some of > > the details, but CMake has this notion of exported targets, and I think > > compiler-rt should really just generate a bunch of exported targets that > > get slurped into a host llvm/clang CMake build. I know this is getting a > > bit off topic, but if anyone wants to talk more about this feel free to > > email me or grab me on IRC. > > > > -Chris > > > > On Nov 3, 2014, at 10:29 AM, Eric Christopher <echristo at gmail.com> wrote: > > > > > > > > On Mon Nov 03 2014 at 9:36:45 AM Tom Stellard <tom at stellard.net> wrote: > > > >> On Fri, Oct 31, 2014 at 11:19:22PM +0000, Eric Christopher wrote: > >> > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <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. > >> > >> Was this the PR: http://www.llvm.org/bugs/show_bug.cgi?id=15732 ? > >> > >> > > Looks like it yes. > > > > -eric > > > > > >> -Tom > >> > >> > > >> > 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? > >> > > > >> > > Thanks, > >> > > Tom > >> > > _______________________________________________ > >> > > LLVM Developers mailing list > >> > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > > > >> > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > -- > Alexey Samsonov > vonosmas at gmail.com> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev