[llvm-commits] [llvm] r142456 - in /llvm/trunk/projects/sample: ./ autoconf/ autoconf/m4/

[Daniel Dunbar]

On Thu, Oct 20, 2011 at 1:34 PM, John Criswell <criswell at illinois.edu> wrote:
> On 10/20/11 2:52 PM, Daniel Dunbar wrote:
>>
>> On Tue, Oct 18, 2011 at 11:11 PM, Anton Korobeynikov
>> <anton at korobeynikov.info>  wrote:

<snip>
>
> It seems that both LLVM projects and LLVM itself have a lot of overlap in
> what their build systems need to do (compiling code, creating linked
> libraries, getting the compile flags right to find LLVM header files, etc.).
>  Perhaps this is the code duplication issue to which Anton refers.

For the most part, you just described "software projects" in general.
Yes, software needs to be built and linked. That doesn't mean that the
primary LLVM project is the right place to design some kind of general
configure/make solution for the world.

I am fine supplying something for users to easily get started with,
but I hate having my hands tied when it comes to working on the LLVM
build because we coupled supplying a solution for users with our build
system.

In general, I think LLVM as a project and LLVM as a set of libraries
have very different problems that make it unlikely they have the same
requirements for a build system:
(a) LLVM is huge, and like many huge projects, has lots of problems
and complexity due to that. Few projects that use LLVM will be
anywhere close it LLVM's size.
(b) LLVM's design for flexible use as a client library has all kinds
of complexity, almost none of which our clients have use for (unless
they themselves are also trying to build as an interconnected set of
libraries -- highly unlikely).
(c) LLVM is a compiler infrastructure, and has associated important
interesting use cases for a build system (self-hosting,
cross-compiling). Clients not building compilers will be unlikely to
care as much about these things.
(d) LLVM is supposed to be highly portable. Clients may or may not
want this, but those who don't aren't likely to care as much about
properly modeling various configuration checks, etc.

>>
>> For example, realistic projects using LLVM would be much better served
>> by having a configuration that is pre-setup to support targeting
>> different versions of LLVM. This is incredibly useful and something we
>> hacked together in KLEE, but would make more sense to be part of the
>> standard template. Obviously, however, that kind of code has no
>> relevance to LLVM TOT.
>
> Trying to have a single code base support multiple versions of LLVM seems
> painful and, for analysis passes especially, nearly futile (it seems that
> analysis passes have to use the internal LLVM API directly, which is as
> fluid as water between releases).  I'm actually not interested in that
> feature.  Is anyone else?

Yes, it is painful, and yes it is very important to some projects. It
is incredibly useful for a number of reasons:
(a) allows testing vs newer versions of LLVM risk free,
(b) important for research projects (like KLEE) where different users
end up having more software built on top of the code and are focused
on their research, not tracking LLVM. Different groups can easily be
at different points in a publication cycle, one group may want a new
LLVM, the other may want as much stability as possible.

> Having said all that, perhaps the old projects system was over-engineered,
> and that over-engineering is flooding over into the current line of
> thinking.  IIRC, the only reason why the Projects system was so complicated
> was because we wanted to let LLVM projects place their source trees and
> object there whereever they wanted.  If we take that feature away and
> require that all projects be checked out into llvm/projects, then all a
> project needs to do to use LLVM's build system is to set the LEVEL variable
> appropriately and include Makefile.common, correct?  The LLVM build system
> loses the cruft, and projects can still use the LLVM build system.  Projects
> can still have configure scripts and specialized build rules for things not
> handled by LLVM's configure script and Makefiles.
>
> This would eliminate cruft *and* prevent code duplication all in a single
> step.

I don't think you understand what I want to do. I want to be able to
change the LLVM build infrastructure without having to worry about it
breaking some piece of compatibility in external projects.
autoconf/make are just a terrible system to treat as "API". I don't
think any system that tries to reuse the LLVM build setup for an
external project is a good idea.

>From my perspective, aside from the historical reasons, there are very
few *pro* reasons to share the build system:

(a) code duplication is not an issue. Very little of the complexity of
the LLVM autoconf/Make system should actually end up being duplicated
in the sample project. It is just done that way currently no because
there is no way to know what users are depending on (see terrible
system to treat as "API"). Conversely, most of the code to deal with
external projects can be eliminated from the LLVM makefiles once the
dependency is broken.

(b) code improvement (ensuring projects benefit from incremental
development) is not really an issue. We rarely improve the build
system, upcoming improvements are much more likely to only be
interesting to the LLVM project, and it is incredibly hard to make
changes without breaking the "API". Since the solution was supposed to
be a "quick start" one, this is not a good tradeoff.

(c) differing requirements: as enumerated above, I feel like LLVM the
project and LLVM as a library have very different use cases.

(d) inactive development. Even if duplication were an issue, in
practice the build system in its current form changes very little, so
the duplication causes little practical harm.

(e) Finally, I don't think LLVM's build system is that great. It would
be one thing if we had an amazing, very well architected, nicely
documented, super fast setup that we really felt other people would
benefit from. I don't think this is the case, the current setup is OK
and workable for LLVM but I don't think it is so good that other
projects should really use it as an example to follow.

My feelings based on the arguments above is that the current setup is
holding us back from making useful improvements for the LLVM project
and its developers, in exchange for very little in return.

 - Daniel

> If people want to place their source and object trees any place they want,
> then they can go through the hassle of building their on build system.  That
> seems like a fair tradeoff.
>
> Thoughts?
>
> -- John T.
>
>>
>>  - Daniel
>>
>>> --
>>> With best regards, Anton Korobeynikov
>>> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>