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

[John Criswell]

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:
>> Hi Daniel,
>>
>> On Wed, Oct 19, 2011 at 03:10, Daniel Dunbar<daniel at zuster.org>  wrote:
>>> Author: ddunbar
>>> Date: Tue Oct 18 18:10:47 2011
>>> New Revision: 142456
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=142456&view=rev
>>> Log:
>>> projects/sample: Import adapted form of current LLVM autoconf/Makefile setup so that projects/sample is standalone and not tied to the LLVM build setup.
>>>   - This currently just moves over all of the behavior from LLVM. Eventually all of the configure checks that are directly needed by the LLVM build setup should probably go away, and the project should manage their own configuration checks if necessary.
>> How we make sure that actual Makefile's and samples/Makefile's will
>> always be in sync?
> We don't. Over time, I would prefer to actively rip out the overly
> complex parts of the samples/Makefiles to be simpler and more tuned to
> sample projects using LLVM (although I have no particular motivation
> to spend a lot of time on this). Conversely, I do intend to actively
> rip out things from LLVM's makefiles which were only there to support
> sample projects.
>
>> I somehow feel that code duplication is not a good approach here.
> The point of projects/sample is to provide a ready made build +
> structure for people who want to set up a project to use LLVM.
> Ideally, it should only depend on llvm-config.
>
> The way I see it, that is completely orthogonal to how LLVM itself
> should build. I view the fact that they were previously in sync as a
> bug, not a feature.

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

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.

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