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

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

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

-Chris

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.
:slight_smile:

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

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.

- Daniel

To be clear, I support saying that these are deprecated (and will be removed in 3.1) in the 3.0 release notes, but we shouldn't rip it out of mainline until after the branch.

-Chris

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

To be clear, I support saying that these are deprecated (and will be removed in 3.1) in the 3.0 release notes, but we shouldn't rip it out of mainline until after the branch.

Right, that was my plan and the impetus for current timing.

- Daniel

Hi John,

I knew I would hear from you. :slight_smile:

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:

As it happens, I knew of two people who used this feature -- myself
(KLEE) and you. :slight_smile:

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.
:slight_smile:

(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 wouldn't agree it is a "very good" way, but I agree it is a way.

The problem is that the "solution" we are providing for this problem
is too intimately tied to the build system of LLVM itself.

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 migration solution for
existing projects using the current functionality.

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

I have no intention of removing or breaking it now, I just want to
deprecate it (as in, declare somewhere that we don't officially
support it, and stop publicizing it).

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.

Right, I completely agree with this, and am completely familiar with
the pain of maintaining an external-to-LLVM client. I'll do my best to
maintain things when/if I ever start actually making changes.

- Daniel

Object now, or hold your peace.

We use it as well for an internal project. Not maintaining a build
system is really a nice feature that got us up to speed very quickly. We
have been using it for the past 4 years, and it's been proven reliable.
We will eventually switch to CMake, but if we can keep it around as long
as possible, it would be nice!

Thanks,
Julien

Hello everybody,

We use it as well for an internal project. Not maintaining a build
system is really a nice feature that got us up to speed very quickly. We
have been using it for the past 4 years, and it's been proven reliable.
We will eventually switch to CMake, but if we can keep it around as long
as possible, it would be nice!

the same holds for me, too. So, I would also be glad if this feature
persists, otherwise, I will presumable move my project to some
git-based solution.

Ciao, Fabian

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 migration solution for
existing projects using the current functionality.

I've used the external build support for 3 different LLVM based projects in the past. I believe it is especially valuable for smaller projects, and helps to keep the barriers to entry low for someone starting to use LLVM. It would be great if we could provide some kind of (documented) alternative solution.

Anna.

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 migration solution for
existing projects using the current functionality.

I've used the external build support for 3 different LLVM based projects in the past. I believe it is especially valuable for smaller projects, and helps to keep the barriers to entry low for someone starting to use LLVM. It would be great if we could provide some kind of (documented) alternative solution.

Anna.

I also use the external build system and find it useful. I agree with
Anna that it lowers barrier to entry and helps spin up small projects
quickly. The easy alternative seems to be to work in the LLVM tree
directly. In the past I found this alternative difficult because of
svn. With the official git mirror it's now a lot easier, but I still
prefer to keep my code physically separate from LLVM's. If the
external build system goes away, it would still be nice to have an
officially maintained sample project.

Thanks,
Jeff

Hi Daniel,

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?

Cheers!

James

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 existing
test-suite and sample project to work that way, instead of removing
them completely.

- Daniel

Sounds good. This was my plan on getting it to work. Alternately I was thinking of a “sample” configure.ac/Makefile.in/etc that people would just include into their own projects via copy and paste.

-eric