llvm dev - Nov 2014 - [LLVMdev] RFC: Timeline for deprecating the autoconf build system?

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.

- 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.

- 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.

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.

Thank you,
Steven Stewart-Gallus

On 11/4/14 12:01 PM, Steven Stewart-Gallus wrote:
> - 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.
Which features, in particular, do you find to be missing?


Cheers,

Jon

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

> On Nov 4, 2014, at 12:34 PM, Jonathan Roelofs <jonathan at
codesourcery.com> wrote:
> 
> 
> 
> On 11/4/14 12:01 PM, Steven Stewart-Gallus wrote:
>> - 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.
> 
> Which features, in particular, do you find to be missing?
I was just writing an email to ask this :)

In particular, if there are changes you’d like to see to
http://llvm.org/docs/CMake.html#frequently-used-cmake-variables
<http://llvm.org/docs/CMake.html#frequently-used-cmake-variables> then
that would be worth discussing (possibly in a separate thread).

Thanks,
Pete
> 
> 
> Cheers,
> 
> Jon
> 
> -- 
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
> _______________________________________________
> 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/f679c402/attachment.html>

On Tue Nov 04 2014 at 12:38:08 PM Jonathan Roelofs <
jonathan at codesourcery.com> wrote:
>
>
> On 11/4/14 12:01 PM, Steven Stewart-Gallus wrote:
> > - 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.
>
> Which features, in particular, do you find to be missing?
>
> There's a bug up thread. Those are the problems we knew about last time
we
asked about this.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/f06322f2/attachment.html>

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

Hello, thank you for the thoughts.
> 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.
Okay, the documentation has come a long way since 3.0 although it
still needs a bit of polish.
> I wouldn't say that much "important functionality is plain
lacking",
> it probably just isn't documented that well.
See the following.
> 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
Correct, but I cannot set it as a default in a configuration file so I
need to specify it for every single package that I compile every time
I configure it. I think this a very basic and obvious feature that
CMake should support.
> 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)
I do in fact need to set the rpath so that I can link to a higher
version of GCC's C++ standard library implementation installed there
as LLVM does not build against an older version of GCC.
> As mentioned above you can override the installation directory
> whenever you like (but it may trigger a rebuild).
> but it may trigger a rebuild
Yeah, that's not what I want.
> But you know you can
> do this right?
> 
> $ make install DESTDIR=/some/path/
That's not the same behaviour at all!
DESTDIR="$HOME/root/usr/local/stow/llvm" installs to
"$HOME/root/usr/local/stow/llvm/$HOME/root/usr/local" instead of
"$HOME/root/usr/local/stow/llvm" which is silly.
> 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).
The fundamental difference between Autotools and CMake is that they
are built for different users. CMake is built for the modern developer
in 2014 on Linux, Windows, Mac OS X or FreeBSD. Autotools is primarily
built for the Free Software enthusiast university student in 1980 who
is compiling a package on his University's Unix like server (which
could be any of many different ones). As such, Autotools is
horrendously difficult for the developer to use but when used properly
is extremely portable and easy to use for the university student who
compiles the project.

Thank you,
Steven Stewart-Gallus

> 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