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

Thu Nov 6 18:09:06 PST 2014

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>