make fails to detect changes in case srcdir != objdir

LLVM makefiles can't detect source changes in case objdir != srcdir, e.g. I've
managed to get my pass listed in 'opt -help' only after removing opt subdir
from objdir and running make again. Re-configuring LLVM also does not trigger
rebuild when running make, e.g. after initial 'configure --enable-targets=x86'
I've managed to get C backend only after removing objdir and re-configuring
(was too lazy to check if 'make clean' is sufficient).

Does anyone know what can be a source for these problems?

  Gregory

LLVM makefiles can't detect source changes in case objdir != srcdir, e.g.

I haven't found that. I build with objdir != srcdir all the time.

I've managed to get my pass listed in 'opt -help' only after removing opt
subdir from objdir and running make again. Re-configuring LLVM also does

It sounds like the dependencies for your pass are not correct. Where
did you put it in the LLVM tree and how did you change the Makefiles?

not trigger rebuild when running make, e.g. after initial 'configure
--enable-targets=x86' I've managed to get C backend only after removing
objdir and re-configuring (was too lazy to check if 'make clean' is
sufficient).

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.

                                -Dave

> I've managed to get my pass listed in 'opt -help' only after removing opt
> subdir from objdir and running make again. Re-configuring LLVM also does

It sounds like the dependencies for your pass are not correct. Where
did you put it in the LLVM tree and how did you change the Makefiles?

One new .cpp file in lib/Transforms/IPO + RegisterPass<> + mention pass in
LinkAllPasses.h; no changes in makefiles.

> not trigger rebuild when running make, e.g. after initial 'configure
> --enable-targets=x86' I've managed to get C backend only after removing
> objdir and re-configuring (was too lazy to check if 'make clean' is
> sufficient).

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.

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

  Gregory

> It sounds like the dependencies for your pass are not correct. Where
> did you put it in the LLVM tree and how did you change the Makefiles?

One new .cpp file in lib/Transforms/IPO + RegisterPass<> + mention pass in
LinkAllPasses.h; no changes in makefiles.

Hmm, that should certainly work. What file are you touching that make
doesn't seem to pick up?

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

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

That's true, but that's autoconf's fault, not LLVM's. :slight_smile:

                              -Dave

> > It sounds like the dependencies for your pass are not correct. Where
> > did you put it in the LLVM tree and how did you change the Makefiles?
>
> One new .cpp file in lib/Transforms/IPO + RegisterPass<> + mention pass in
> LinkAllPasses.h; no changes in makefiles.

Hmm, that should certainly work. What file are you touching that make
doesn't seem to pick up?

Sorry, can't tell you that now: I've switched to srcdir == objdir configuration.

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

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

That's true, but that's autoconf's fault, not LLVM's. :slight_smile:

And what was the reason for picking autoconf?

  Gregory

> > > 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 :slight_smile:
>
> That's true, but that's autoconf's fault, not LLVM's. :slight_smile:

And what was the reason for picking autoconf?

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

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

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

                                  -Dave

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

I think in this situation the second configure uses the cached stuff
from the first run...

Slightly offtopic, I noticed this project which does something very
similar to what you describe:
http://code.google.com/p/quagmire/

I don't know what its current state is, but is something worth keeping
an eye on IMHO.

Best regards,
--Edwin

Very interesting. I'll have a look!

                             -Dave