similar to: [LLVMdev] RFC/Heads Up: Deprecating External Build Support

Hi John, I knew I would hear from you. :) On Tue, Oct 11, 2011 at 2:38 PM, John Criswell <criswell at illinois.edu> wrote: > On 10/11/11 3:24 PM, Daniel Dunbar wrote: >> >> Hi all, >> >> I would like to deprecate the LLVM project's "official" support of >> setting up the Makefiles / autoconf configurations in such a way that >> external

On 10/11/11 3:24 PM, Daniel Dunbar wrote: > Hi all, > > I would like to deprecate the LLVM project's "official" support of > setting up the Makefiles / autoconf configurations in such a way that > external projects are encouraged to leverage them in their own build. > > I am mostly referring to the things documented in docs/Projects.html > and projects/sample.

On Oct 11, 2011, at 3:02 PM, Daniel Dunbar wrote: > If the community thinks this is an important problem for LLVM to > address, then I think the ideal solution is that we provide a set of > autoconf/makefile/whatever foo that uses llvm-config and so on, but > doesn't try and do things like include the LLVM Makefiles or the LLVM > autoconf files. This would also provide a

On Tue, Oct 11, 2011 at 11:49 PM, Anna Zaks <ganna at apple.com> wrote: > On Oct 11, 2011, at 3:02 PM, Daniel Dunbar wrote: >> If the community thinks this is an important problem for LLVM to >> address, then I think the ideal solution is that we provide a set of >> autoconf/makefile/whatever foo that uses llvm-config and so on, but >> doesn't try and do things

Initially I don't actually plan on breaking anything, just removing the idea that this is something we encourage people to do. So Clang and your project would keep working. Longer down the road, if I started changing things I would naturally be keeping Clang up to date (I don't regard it as "External"), but you would end up having to make the same changes to your project. -

Hi Daniel, Will Clang be changed to follow this or will it be special-cased? My own python compiler currently uses the same setup Clang does (as you describe), and it works rather well. I'd like to continue to do whatever Clang (or other frontends) do... Cheers, James ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf Of

On Oct 11, 2011, at 1:24 PM, Daniel Dunbar wrote: > Hi all, > > I would like to deprecate the LLVM project's "official" support of > setting up the Makefiles / autoconf configurations in such a way that > external projects are encouraged to leverage them in their own build. +1. Please make sure Projects.html is updated, and please add a note to the 3.0 release

Ok, based on the responses on this thread I'm going to change my plan a bit. I didn't expect that that many people were using the existing set up. I still want to deprecate the current sample setup which is intimately tied in with LLVM's own build system (so that we are more free to make changes to how the project itself builds). However, I will plan on doing this by refactoring the

On Oct 11, 2011, at 2:33 PM, Chris Lattner wrote: > > On Oct 11, 2011, at 1:24 PM, Daniel Dunbar wrote: > >> Hi all, >> >> I would like to deprecate the LLVM project's "official" support of >> setting up the Makefiles / autoconf configurations in such a way that >> external projects are encouraged to leverage them in their own build. >

On 6/18/15 6:49 PM, Eric Christopher wrote: > Hi John, > > Long term we don't want to keep the burden of two build systems in > tree. CMake is turning out to be the build system we want because of > its multi-platform support, etc and as soon as the CMake system can do > everything we can do with the autoconf/makefile build I plan on > turning down the support for that

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

Dear All, Will the LLVM project system (the extension to the build system that allows sub-projects to reuse the LLVM Makefiles) be maintained long term, or is the slow push to CMake intending to deprecate this functionality? We used this feature a lot for research projects at UIUC, but if the current maintainers of the build system are planning on deprecating it, I'll have my students

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

----- Original Message ----- > From: "Eric Christopher" <echristo at gmail.com> > To: "John Criswell" <jtcriswel at gmail.com>, LLVMdev at cs.uiuc.edu, "Chris Bieneman" <beanz at apple.com> > Sent: Thursday, June 18, 2015 7:14:06 PM > Subject: Re: [LLVMdev] Long-Term Support for LLVM Projects Extension to Build System? > > > On

> 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 All, I fear starting another centi-thread on this but I'll give it a shot. We're currently supporting two build systems which is definitely one more than we (or I) want to support. I don't know of any support in autoconf past the --host/--build/--target case that's not supported in cmake. I'll send out an assertion here that this support isn't necessary and any system

On Wed, May 22, 2013 at 8:33 PM, Charles Davis <cdavis5x at gmail.com> wrote: > > On May 22, 2013, at 5:14 PM, Eric Christopher wrote: > > > Hi All, > > > > Can anyone see good a reason not to move to cmake as our only build > > configuration system and drop future support for autoconf + makefiles > > now that 3.3 has branched? > +1. > - CMake

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