search

trquinn / changa

Clone of UIUC public ChaNGa
1 stars 2 forks source link

Remove Makefile.dep from version control to avoid dependency-path issues #6

Closed insaneinside closed 10 years ago

insaneinside commented 10 years ago

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:

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

trquinn commented 10 years ago

The "clean" target should also be modified to remove "Makefile.dep".

insaneinside commented 10 years ago

Modified as requested.