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
Reid Kleckner
2014-Nov-05 00:04 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
On Tue, Nov 4, 2014 at 1:17 PM, Dan Liew <dan at su-root.co.uk> wrote:> 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.I agree, I wanted to spend some time today trying to make this work. I think part of the issue is that the current standalone clang build is designed to work when all you have is a build directory, not an install directory. This way you can have two XCode IDE instances: one for LLVM and once for Clang, and just hit build in LLVM before building Clang. It's one level of manual dependency management, but worth it for the increase in responsiveness. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/7ec60b14/attachment.html>
Tom Stellard
2014-Nov-13 15:18 UTC
[LLVMdev] RFC: Timeline for deprecating the autoconf build system?
On Tue, Nov 04, 2014 at 04:04:45PM -0800, Reid Kleckner wrote:> On Tue, Nov 4, 2014 at 1:17 PM, Dan Liew <dan at su-root.co.uk> wrote: > > > 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. > > > I agree, I wanted to spend some time today trying to make this work. >I have filed a bug for this: http://www.llvm.org/bugs/show_bug.cgi?id=21560 If anyone has additional information they would look to add, please do so. Thanks, Tom> I think part of the issue is that the current standalone clang build is > designed to work when all you have is a build directory, not an install > directory. This way you can have two XCode IDE instances: one for LLVM and > once for Clang, and just hit build in LLVM before building Clang. It's one > level of manual dependency management, but worth it for the increase in > responsiveness.> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev