Remakefile in parent directory

[bobot]

Feature wish: remake could look for a Remakefile in the parent directory instead of failing when there is no Remakefile.

This will be useful only when the users installed remake in their path. But developers of a project that use remake can take the time to do that.

Details:

• Execute as if started from the parent directory that contains the Remakefile.
• For the targets on the command line:
  1. try to match them pristine
  2. if there is no match, prepend them with the original directory (./file can be used by the user to disambiguate)
• As git by default, stop looking at filesystem boundary.
• Execute the version of remake that is specified in the Remakefile before doing anything (in that case the first remake just look for a Remakefile in the parent directory). Since remake can be distributed with a project the version can be custom.

[silene]

Removing the need to run remake in the same directory as the .remake file is something I want to eventually implement. With respects to the details, here are the issues I have uncovered.

First, I agree that remake should be executed as if it had been executed from the closest parent directory containing a Remakefile. More precisely, since remake supports option -f to choose a Remakefile, it currently needs to be run from the directory containing file .remake. So we have some conflicting behavior here, since the very first time remake is run, there is no .remake file to detect the top directory of a project. A way to work around this issue would be to consider option -f to be a special case that always requires the user to run remake -f (the server process at least) from the top directory of a project. Another way to solve it would be to always store .remake next to Remakefile (this is currently not the case).

Regarding the interpretation of targets, I feel that they should always be preprended with the relative path to the directory containing .remake (that is, your point 2). I understand that one would like "pristine" interpretation for targets like "clean". But this opens a can of worms. For instance, consider target "toto.o" built from directory "src". It will match the target "%.o", but compilation will fail since there will be no file "toto.c" in the top directory. I have taken the habit of having rules for targets like "src/clean", "doc/clean", and so on, which solve the issue nicely (even if their purpose was originally different).

Unfortunately, I have no idea how to portably check for filesystem boundary.

Finally, for version incompatibility between remake and Remakefile, I do not have any good solution. Sure, remake could check if Remakefile contains some syntax pointing to a particular executable (e.g. a shebang #!./remake -f on the first line) but it would only solve the issue when there is a single Remakefile. But in the long run, I intend to support interactions between several Remakefiles, e.g. one per project and with interprocess dependencies.

[silene]

Since commit 189482a, remake can be called by the user from any subdirectory. With respect to the original report, missing features are: phony targets are not special-cased and filesystem boundaries are not checked.