[LLVMdev] make fails to detect changes in case srcdir != objdir

David Greene dag at cray.com
Tue Jan 5 12:21:53 PST 2010


On Tuesday 05 January 2010 13:33, Gregory Petrosyan wrote:

> > > > A non-build after reconfigure is not really a problem.  If nothing in
> > > > the configuration has changed configure is smart enough not to update
> > > > anything so make doesn't see any changes.
> > >
> > > Yes, but in my case support for new targets should be built in.
> >
> > What do you mean?
>
> I've done these:
>
> 	1) configure --enable-targets=x86
> 	2) make
> 	3) configure --enable-targets=all
> 	4) make
>
> and after it I still did not had e.g. C backend.

Ah.  I actually don't know what configure does in that case.  I suppose
it depends on what .in files actually use the target list.  This could be
a real problem, I just don't know enough about the build system to be sure.

> > > It is entirely possible that I've screwed something up, although I've
> > > tried to follow LLVM docs as closely as possible. LLVM build system is
> > > really not the nicest part of LLVM :-)
> >
> > That's true, but that's autoconf's fault, not LLVM's.  :)
>
> And what was the reason for picking autoconf?

Don't ask me, it's not what I would have done.  :)

But to be fair, at the time autoconf was really the only game in town.
Even now, only CMake really competes in this space.

Then again, neither one satisfies Joel Test #2:

http://www.joelonsoftware.com/articles/fog0000000043.html

I've wondered for a long time why software systems don't build a build system
around a tool that's actually designed for it.  Like make.  In fact I wondered
so much that I went and did it.  Parallel configure/build/test is a really
nifty thing.  It's fun seeing regression tests running before the software
build is complete.  :)

Make is not everyone's cup of tea but for those of us crazy enough to write in
something akin to declarative LISP, it's a nice diversion from boring old 
C++ metaprogramming.  :)

                                  -Dave



More information about the llvm-dev mailing list