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

[Daniel Sanders]

> Installation prefix is set using the CMAKE_INSTALL_PREFIX cache
> variable. You can set it at configure time,
> 
> $ cmake -DCMAKE_INSTALL_PREFIX=$HOME/root/usr/local
> /path/to/llvm/src

This touches on a point where I think cmake is a bit weak for end users. With autotools, pretty much everything an end-user needs to know is in './configure --help' and it doesn't normally have too much information. CMake doesn't really have a good equivalent for this. It's clearly trying to achieve the same kind of thing through --help-variable-list, --help-variables, and '--help-variable var' but the latter requires you to know the variable name and the former two print _everything_ (including things like CMAKE_ARGC, and CMAKE_ARGV0). To summarize, CMake is fairly well documented in my opinion but it doesn't guide the end-user very well.

That said, I'm broadly in favour of dropping autotools support. CMake builds are significantly faster in my experience (especially with ninja and BUILD_SHARED_LIBS=ON) and I'm not keen on the testing burden of supporting two build systems.

Tom: You probably already know this but one thing to mention is that utils/release/test-release.sh currently does an autotools-based build.

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Dan Liew
> Sent: 04 November 2014 21:48
> To: Steven Stewart-Gallus
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] RFC: Timeline for deprecating the autoconf build
> system?
> 
> Hi
> 
> On 4 November 2014 19:01, Steven Stewart-Gallus
> <sstewartgallus00 at mylangara.bc.ca> wrote:
> > I am an actual end user of LLVM who builds it from source and not a
> > developer of it so I think I have an important perspective that is not
> > represented here. Also I am pretty sure the llvmdev mailing is heavily
> > biased and might not reach actual end users of LLVM. I use the
> > Autotools build system for a number of reasons. If compromises or
> > reasonable workarounds could be found I would be okay with the switch
> > to CMake.
> >
> > - CMake is poorly documented and difficult to use as an end
> >   user. There are a number of arcane switches and settings that are
> >   hard to find and figure out what they do. Moreover, certain
> >   important functionality is just plain lacking.
> 
> Have you seen the docs for CMake3.0 [1] (see cmake-buildsystem
> especially)? They certainly aren't perfect but they are considerably
> better than what was there before.
> 
> I wouldn't say that much "important functionality is plain lacking",
> it probably just isn't documented that well.
> 
> > - I already have an Autotools configuration file that sets default
> >   settings for the local installation prefix (to
> >   "$HOME/root/usr/local") and the LDFLAGS (to
> >   "-Wl,-rpath,${HOME}/root/usr/local/lib
> >   -Wl,-rpath,${HOME}/root/usr/local/lib64"). I don't if it's possible
> >   to set such defaults for CMake and even if it is the difficulty in
> >   finding how to do so is a bad sign.
> 
> Installation prefix is set using the CMAKE_INSTALL_PREFIX cache
> variable. You can set it at configure time,
> 
> $ cmake -DCMAKE_INSTALL_PREFIX=$HOME/root/usr/local
> /path/to/llvm/src
> 
> you can even change it after configuring easily later by running
> 
> $ make edit_cache
> 
> which will launch a nicer editor for the variables (e.g. ccmake or cmake-gui).
> 
> I'm don't think it's necessary to set the rpath. If you read [2]
> you'll see that you can just run the binaries in the build tree and
> they have rpath set correctly (the installed binaries have rpath
> removed)
> 
> If you really wanted to you could probably hack some of CMake's flags
> to set rpath but I don't understand why you want to do this. You can
> just build against LLVM's build tree to do development.
> 
> 
> > - In Autotols the installation directory is overridable at install
> >   time so I can set the prefix variable to a different directory such
> >   as "$HOME/root/usr/local/stow/llvm" and using GNU Stow have easy
> >   package management and isolation between software. CMake does not
> >   offer such a capability or is so poorly documentated that it is
> >   impossible to find out how to do so.
> 
> As mentioned above you can override the installation directory
> whenever you like (but it may trigger a rebuild). But you know you can
> do this right?
> 
> $ make install DESTDIR=/some/path/
> 
> So then the project will be installed at
> 
> /some/path/<CMAKE_INSTALL_PREFIX>/
> 
> > Overall, CMake isn't a bad build system for actually building software
> > but simply lacks the appropriate polish and documentation that makes
> > it easy for end users to use.
> 
> The documentation is probably the biggest problem. I actually quite
> liked CMake (apart from its syntax and variable scoping rules) once I
> understood the bits I needed to understand.
> I probably have a very different perspective from many though given
> that I used CMake first and then tried autotools afterwards (I'll be
> honest... I don't like it very much).
> 
> 
> [1] http://www.cmake.org/cmake/help/v3.0/
> [2] http://www.cmake.org/Wiki/CMake_RPATH_handling
> --
> Dan Liew
> PhD Student - Imperial College London
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev