David Chisnall
2014-Nov-02 16:48 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
On 2 Nov 2014, at 14:17, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:> Requiring cmake for NetBSD is not acceptable as it is almost as heavy as > a C++ compiler itself. That said, I don't really care about the > Makefiles, just about configure and the associated loggic to craete > Config.h and friends. I would expect FreeBSD to have similar concerns.For the FreeBSD base system, we use a bmake-based build system for LLVM, but that is based on the Makefiles generated by CMake. I believe that we're now using CMake for the version of LLVM in ports. David
Joerg Sonnenberger
2014-Nov-03 12:17 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
On Sun, Nov 02, 2014 at 04:48:58PM +0000, David Chisnall wrote:> On 2 Nov 2014, at 14:17, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > > > Requiring cmake for NetBSD is not acceptable as it is almost as heavy as > > a C++ compiler itself. That said, I don't really care about the > > Makefiles, just about configure and the associated loggic to craete > > Config.h and friends. I would expect FreeBSD to have similar concerns. > > For the FreeBSD base system, we use a bmake-based build system for LLVM, > but that is based on the Makefiles generated by CMake. I believe that > we're now using CMake for the version of LLVM in ports.The primary question is how do you create Config.h and friends, especially the tools version during early release build. Joerg
David Chisnall
2014-Nov-03 12:28 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
On 3 Nov 2014, at 12:17, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:> On Sun, Nov 02, 2014 at 04:48:58PM +0000, David Chisnall wrote: >> On 2 Nov 2014, at 14:17, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: >> >>> Requiring cmake for NetBSD is not acceptable as it is almost as heavy as >>> a C++ compiler itself. That said, I don't really care about the >>> Makefiles, just about configure and the associated loggic to craete >>> Config.h and friends. I would expect FreeBSD to have similar concerns. >> >> For the FreeBSD base system, we use a bmake-based build system for LLVM, >> but that is based on the Makefiles generated by CMake. I believe that >> we're now using CMake for the version of LLVM in ports. > > The primary question is how do you create Config.h and friends, > especially the tools version during early release build.We keep the version generated by CMake in the source tree for the version in base. For the version in ports, CMake generates it when it builds. David
Brooks Davis
2014-Nov-04 19:08 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
On Sun, Nov 02, 2014 at 04:48:58PM +0000, David Chisnall wrote:> On 2 Nov 2014, at 14:17, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > > > Requiring cmake for NetBSD is not acceptable as it is almost as heavy as > > a C++ compiler itself. That said, I don't really care about the > > Makefiles, just about configure and the associated loggic to craete > > Config.h and friends. I would expect FreeBSD to have similar concerns. > > For the FreeBSD base system, we use a bmake-based build system for > LLVM, but that is based on the Makefiles generated by CMake. I > believe that we're now using CMake for the version of LLVM in ports.For most versions we're using autoconf because it lets us build clang against an installed LLVM. The autoconf build system almost supports this (you need to symlink a couple installed files into the build tree), but AFACT the cmake build system doesn't. It would be really useful if I could build clang against an installed LLVM and LLDB against an install clang and LLVM. The reason is that I'd prefer not to require that users install clang when they just want LLVM and right now the only alternative would be to rebuild LLVM with clang and then toss the result. The ability for our package system to produce multiple packages from the same build is coming soon, but I foresee a maintenance nightmare when I have to figure out which bits should end up in which package given the way libraries and executables come and go in LLVM. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/f2a95971/attachment.sig>
Dan Liew
2014-Nov-04 21:17 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
On 4 November 2014 19:08, Brooks Davis <brooks at freebsd.org> wrote:> On Sun, Nov 02, 2014 at 04:48:58PM +0000, David Chisnall wrote: >> On 2 Nov 2014, at 14:17, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: >> >> > Requiring cmake for NetBSD is not acceptable as it is almost as heavy as >> > a C++ compiler itself. That said, I don't really care about the >> > Makefiles, just about configure and the associated loggic to craete >> > Config.h and friends. I would expect FreeBSD to have similar concerns. >> >> For the FreeBSD base system, we use a bmake-based build system for >> LLVM, but that is based on the Makefiles generated by CMake. I >> believe that we're now using CMake for the version of LLVM in ports. > > For most versions we're using autoconf because it lets us build clang > against an installed LLVM. The autoconf build system almost supports this > (you need to symlink a couple installed files into the build tree), but > AFACT the cmake build system doesn't. > > It would be really useful if I could build clang against an installed LLVM > and LLDB against an install clang and LLVM.CMake can support this. We need to make use of the "exporting targets" feature that CMake offers so that clients can build against LLVM libraries. LLVM has actually been exporting this information for a while and it is documented here [1]. To further complicate matters the clang CMake build system supports two modes. In tree build (i.e. inside tools/clang) and an out of tree build. The problem IIRC with the out of tree build is that the CMake clang build system does not try to use this information at all and instead tries to get its information from the llvm-config executable which doesn't feel very clean. I should warn that I've never tried the "out of tree" build of clang so I don't know how well it works. [1] http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project