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

Thu Nov 13 07:38:56 PST 2014

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