[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
Tom Stellard
tom at stellard.net
Mon Nov 3 09:40:11 PST 2014
On Sat, Nov 01, 2014 at 02:26:08AM +0200, Pasi Parviainen wrote:
> On 1.11.2014 0:08, Tom Stellard 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.
>
> Because of these differences between build systems, I decided to start
> my personal project recently to bring up each build system to equal
> grounds for a platform which I care (which is FreeBSD). Motivation for
> this has been to have identical test results (and builds) from each
> other, in the case autoconf build system is retired.
>
This sounds like a good project, do you have a list of remaining
differences?
-Tom
> > 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?
>
> At least better job could be done for canonicalization of architectures
> within cmake configurations. For example at the moment some LLVM tests
> does not run with cmake builds for x86_64 FreeBSD, since it identifies
> itself as "amd64" for cmake, which cascades down to lit testing
> infrastructure. That's an easy example what I have faced at least so far.
>
> Pasi
>
> > 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).
> >
> > - 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
> >
>
More information about the llvm-dev
mailing list