[LLVMdev] RFC/Heads Up: Deprecating External Build Support
criswell at illinois.edu
Tue Oct 11 14:38:53 PDT 2011
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.
> My justification:
> (1) I believe few people use these capabilities.
I use these capabilities extensively in numerous research and
open-source projects. Those projects include:
1) Automatic Pool Allocation (publicly available in the poolalloc module)
2) SAFECode (publicly available in the safecode module)
3) Giri (publicly available but currently of no real consequence)
4) A diagnosis tool developed by one of our graduate students
5) An integer overflow detector tool
The first two I care very much about; we are tracking mainline and want
to keep them working so that we can have something for people to use
when LLVM 3.0 hits the streets.
Additionally, SAFECode copies Clang into its own source tree (for a
variety of reasons which I'll skip over for the purposes of this
discussion). The project build system actually makes this very easy;
very few Clang Makefiles needed modification to enable Clang to compile
within SAFECode. If my projects have to create their own build system,
then I'll have to duplicate LLVM's build machinery in the SAFECode
project to build Clang.
The other projects I listed are less important; I merely list them so
that you have an idea of how much work you'll make for me if you remove
the Projects functionality.
> (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.
IMHO, the LLVM Projects setup is a very good way for people to write
their own LLVM passes without having to patch the LLVM source tree. It
alleviates the need to create a whole new build system, it allows one to
build LLVM and one's project(s) all in a single go, and one's project
source code is organized just as it would be within LLVM's source base
(more or less).
I suspect that removing the Project functionality will also increase the
demand for a switch to git as people will prefer to write their LLVM
passes as patches to the LLVM source base instead of as a separate project.
> (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.
Building the Projects functionality was a pain (I'm the one that
originally added the support for it, so I know). If it's getting in the
way of important changes to the build system, then perhaps it should be
removed despite the fact that it'll create more work (headaches) for me.
That said, I ask for two things:
1) Please don't remove functionality like this right before an LLVM
release. Both SAFECode and Poolalloc use this feature, and I don't want
to have to scramble at the last minute to make them work again with the
upcoming LLVM 3.0. If it has to go, please wait until development for
LLVM 3.1 begins (waiting longer would be even better).
2) Please only remove it if it's currently getting in the way of some
important bug fix, refactoring, or enhancement. If you're removing it
just because LLVM Core doesn't need it, then you're not fixing anything
in LLVM, and you're breaking things that use LLVM.
-- John T.
> Object now, or hold your peace.
> - Daniel
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev