[LLVMdev] RFC/Heads Up: Deprecating External Build Support
james.molloy at arm.com
Wed Oct 12 00:08:24 PDT 2011
Yes, that's fine, go ahead. But as there may be others in my position that
are less vocal, could you please shout about any such changes as they go in
to Clang on the list so I and others can know how and when to update our
build systems as opposed to piecing it together from a bunch of commits when
we svn update?
From: daniel.dunbar at gmail.com [mailto:daniel.dunbar at gmail.com] On Behalf Of
Sent: 11 October 2011 22:42
To: James Molloy
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] RFC/Heads Up: Deprecating External Build Support
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.
On Tue, Oct 11, 2011 at 1:56 PM, James Molloy <James.Molloy at arm.com> wrote:
> 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...
> From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] On Behalf
Of Daniel Dunbar [daniel at zuster.org]
> Sent: 11 October 2011 21:24
> To: LLVM Developers Mailing List
> Subject: [LLVMdev] RFC/Heads Up: Deprecating External Build Support
> 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.
> My justification:
> (1) I believe few people use these capabilities.
> (1a) The primary consumer that people have used in the past was
> llvm-test-suite. That was broken in its own way, and the test suite
> can now be used independently of an LLVM installation. This makes it
> much more useful as a production test suite for compilers (vs. a test
> suite for a research project).
> (2) They are fragile and really not a very good way to structure an
> external project. It is much better for external projects to just
> structure themselves as any other open source project would and use
> tools like llvm-config to gather build information.
> (3) The official support is not particularly well known, and is easy
> to break. Considering Makefiles and autoconf files as part of a
> project API is painful, at best, and makes refactoring of project
> structure difficult.
> Object now, or hold your peace.
> - Daniel
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you.
More information about the llvm-dev