similar to: [RFC] Deprecating autoconf: Let's do 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

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

Hi LLVMDev, The following issues have been fixed since the last update I sent out. Completed: * Bug 19462 - Use the INSTALL(EXPORT ...) to export CMake definitions * Bug 21561 - Update release scripts to use CMake These issues are still outstanding. Classification of blocking vs non-blocking are my own opinions, please let me know if you disagree. All non-blocking issues are still serious bugs

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

Hi Brenden, Thanks for the heads up. I don’t expect that to be a blocker for deprecating autoconf because autoconf doesn’t have an equivalent of LLVMExports.cmake. That said it is a real issue and I’ll track it with the other issues on this list, and I’ve added it as a dependency on the meta bug (PR15732) to make it easier to keep track of. Thanks, -Chris > On Jul 29, 2015, at 4:48 PM,

On Fri, Nov 06, 2015 at 04:17:04PM -0800, Hans Wennborg via llvm-dev wrote: > On Fri, Nov 6, 2015 at 9:56 AM, Chris Bieneman via llvm-dev > <llvm-dev at lists.llvm.org> 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

Hi Chris, Looking forward to continued support for CMake! Along that note, I wanted to add one bug to your list of things to track, which to me seems up your alley but maybe was filed in the wrong bucket (or is actually someone else's problem). Bug 24154 - CMake shared files are broken in llvm-3.7-dev Cheers, Brenden On Wed, Jul 29, 2015 at 1:20 PM Chris Bieneman <beanz at

Hi all, Time for another update on the status of the CMake build system. Completed: * Bug 18496 - [cmake] .S assembly files not compiled by cmake in libclang_rt.ARCH * Bug 22725 - lldb build with cmake fails with "Program error: Invalid parameters entered, -h for help. " * Update GettingStarted to prefer CMake Still Outstanding: * Bug 14109 - CMake build for compiler-rt should use

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

Hi, On Tue, Jan 19, 2016 at 8:09 PM, Chris Bieneman <beanz at apple.com> wrote: > I think the right solution here is to fix LLVM_BUILD_LLVM_DYLIB and LLVM_LINK_LLVM_DYLIB (which should work) rather than fixing BUILD_SHARED_LIBS which was never intended to work for this use case. > > Either way, patches welcome. This seems to be due to your commit http://reviews.llvm.org/D13841 ,

> On Jan 14, 2016, at 11:22 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Jan 14, 2016, at 9:38 AM, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >>> On Jan 14, 2016, at 5:18 AM, Dan Liew <dan at su-root.co.uk> wrote: >>> >>> On 14 January 2016 at 11:24, David Jones via llvm-dev

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 that use LLVM and have to deal with the slight differences in output between the two build systems. It seems like most people are using CMake at this point, so my questions to the community are: - Is

> On Jan 12, 2016, at 9:39 AM, Reid Kleckner <rnk at google.com> wrote: > > Sounds like a plan. > > Should we leave behind a simple ./configure script that checks for cmake, and if present, runs something like 'cmake -G"Unix Makefiles" .'? I think it's nice if the "standard" Unix way of building with "./configure && make"

On 01/17/2016 02:53 PM, Dan Liew wrote: > @Brad: CC'ing you because I know you use > ``llvm_map_components_to_libnames()`` so you will likely have > something to say about it breaking. I'm using it in CastXML but that could easily be adapted to something different if needed. The larger concern is that that API is the documented way to use LLVM in an application with CMake so

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

I’ve got some new patches and some numbers. The patches are all the changes required to strip intrinsics using the preprocessor defines I showed in my earlier patches. It actually isn’t that much change to LLVM. Clang will need similar changes too. There were only 9 files that referenced target intrinsics outside the corresponding target. These patches are still WIP, and there is some nastiness,

> 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