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

> On Oct 31, 2014, at 4:19 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <tom at stellard.net <mailto:tom at stellard.net>> 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

On Mon, Nov 3, 2014 at 9:26 AM, Tom Stellard <tom at stellard.net> wrote: > On Fri, Oct 31, 2014 at 04:31:47PM -0700, Bob Wilson wrote: > > > > > On Oct 31, 2014, at 4:19 PM, Eric Christopher <echristo at gmail.com> > wrote: > > > > > > > > > > > > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <tom at stellard.net >

On Fri, Oct 31, 2014 at 11:19:22PM +0000, Eric Christopher wrote: > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <tom at stellard.net> 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

Sorry I’m a little late to this thread. There has been some discussion about using CMake to generate shared libraries. Since I’ve done some patches in this area recently I thought I’d take a minute to explain the current state of things. Historically LLVM’s CMake build system has been able to produce shared libraries for each of the llvm static libraries. My patch (r220490) added the llvm-shlib

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

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

Sent from my iPhone > On Oct 31, 2014, at 17:40, Steve King <steve at metrokings.com> wrote: > >> On Fri, Oct 31, 2014 at 3:08 PM, Tom Stellard <tom at stellard.net> wrote: >> - Is there any technical reason why the remaining autoconf users can't switch >> to CMake? > > Last time I tried, the CMake build was missing some pieces required > for

> On Oct 31, 2014, at 4:45 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Fri, Oct 31, 2014 at 4:31 PM, Bob Wilson <bob.wilson at apple.com <mailto:bob.wilson at apple.com>> wrote: > >> On Oct 31, 2014, at 4:19 PM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote: >> >> >>

Hi LLVMDev, Since my last update we’ve landed patches for these issues: * Bug 14200 - -fno-rtti not in cxxflags given by llvm-config * Bug 23746 - test-suite lacks CMake support * Bug 25059 - CMake libllvm.so.$MAJOR.$MINOR shared object name not compatible with ldconfig On my last thread Jonathan Roelofs pointed out that there is a workaround for Bug 21568 (Cannot add rpath), so I’m making it

As somebody who's currently hosting LLVM on a platform (OpenVMS Itanium) that has configure but not a working CMake (we're working to fix that but there are some tricky issues), I would appreciate if you didn't scrub the existence of configure from the source or the documentation. Perhaps keep pointers to the older pages and link to them from the downloads pages or something with an

Keeping the documentation with large warnings is sufficient. It would at least let somebody then grab an older version's makefiles if they are so inclined/interested. I have no problem with you yanking the files, just the fact that older versions did have configure/makefiles. I only spoke up when I saw the suggestion for removing the online documentation. John -----Original Message-----

> On Nov 9, 2015, at 3:21 PM, Jonathan Roelofs via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On 11/9/15 4:02 PM, John Reagan via llvm-dev wrote: >> Keeping the documentation with large warnings is sufficient. It >> would at least let somebody then grab an older version's makefiles if >> they are so inclined/interested. I have no problem

On 11/9/15 5:49 PM, John Reagan wrote: > That would be fine with me. I just don't want some new visitor to > come along and see "CMake only" and get discouraged and leave. Well, it is going to be "CMake only". Anyone who depends on autotools is going to be stuck on whatever the last revision is that we shipped with it. And I really don't see it being feasible

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

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

Hi LLVMDev, There’s been a good bit of progress this month, and with the dev meeting later this week I thought I’d send out a second update. There are only two outstanding blocking issues that don’t have patches proposed, PR 21568 & PR 23947. I would greatly appreciate if someone who works on Mips would take a look at PR 23947. The following issues have been marked as fixed since the last

So, we’ve had this conversation a few times, and I wanted to coalate a status report for all the interested parties. Here's the outstanding work and my (not necissarily correct) view of the status and importance of each one: * Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable - There are patches on the bug that we should review, test, and land * Bug 14109 - CMake

Paul, you can also just not test autoconf. Why does it matter to you if the autoconf files are there or not ? On May 22, 2013, at 8:30 PM, "Redmond, Paul" <paul.redmond at intel.com> wrote: > Yes please. > > On the practical side, our internal CI does cmake/autoconf x debug/release > x gcc/clang (on linux). Cutting out autoconf reduces the number of >

CMake is just a makefile (or <insert build system here>) generator. So something like cmake <stuff>; make check-all works already. Or did you have something else in mind? -eric On Wed, May 22, 2013 at 4:28 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> Hi All, >> >> I fear starting another centi-thread on this but I'll

Now that autoconf is going away soon, I figured I'd try building using CMake. I checked out llvm, cfe and lldb from the SVN server, and followed the basic build instructions. cmake -DBUILD_SHARED_LIBS=OFF -DCMAKE_INSTALL_PREFIX=/tools/llvm/svn_head -DLLVM_TARGETS_TO_BUILD="X86;CppBackend" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON ../llvm Everything worked well, and in