[LLVMdev] RFC: Timeline for deprecating the autoconf build system?

Chris Bieneman beanz at apple.com
Tue Nov 4 10:56:08 PST 2014


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>


More information about the llvm-dev mailing list