trquinn/changa — pull request #6 by insaneinside (2014-03-14 01:38:06+00:00)
Title: Remove Makefile.dep from version control to avoid dependency-path issues

Discussed via email; copy thereof follows.

The issue is simple: unless we make use of the VPATH feature (e.g by putting `VPATH=@srcdir@` in Makefile.in), `make' will look for the paths specified in Makefile.dep -- which are relative to the source directory. That's just fine for in-source builds, but when my generated Makefile for an out-of-source build includes Makefile.dep for someone else's (in-source!) build, it says,
> hmm, okay. I need to make "Reductions.o". ...well, let's see...
> okay, I need to find or make a file that has **path** "Reductions.cpp" for that.
> I don't have a file at **path** "Reductions.cpp", and you didn't tell me how to make one.

Make is very literal about how it interprets target/dependency names: VPATH aside, it takes a file name and tries to stat it.

This is fine when I use a Makefile.dep generated for my particular build using the out-of-source-build-enabled version of ChaNGa, but the version of Makefile.dep that's checked-in to version control is from ... 3 January 2013. Yikes?

So do we check in a new version of Makefile.dep every time we add an #include to some source file? Keeping `configure' in-sync with configure.ac (and now cuda.ac) is bad enough, but that at least makes some sense to me. And if I generate a Makefile.dep for an out-of-source build and check it in to version control, I break the compile process for anyone not using the same build directory relative to the ChaNGa sources as me.

VPATH is one possible fix, yes. I'm not very fond of the VPATH mechanism: it's kludgy and very generic ("if you can't find *any* file, slap *this string* on the front and see if the result is a valid name"), and [it's not even consistent in its behavior](https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Make-Target-Lookup.html):
> It seems the sole solution that would please every make implementation is to never rely on VPATH searches for targets. In other words, VPATH should be reserved to unbuilt sources.

(We should read the final sentence of the above quote as "Never use VPATH to find a file that could potentially be generated via a Make rule" -- which, I think, is exactly what we would be using it for, in the case of Charm++-generated `.decl.h` and `.def.h` files.)