I am thinking about recursive make

gistfile1.md

So normally the way you run make is you just run

make

It searches for a file Makefile in the current directory and runs it. Yay! Sometimes, you want to make something in a subdirectory. You could type

cd subproject && make

But that's annoying, so make lets you do

make -C subproject

And it runs make "in that directory". Okay, useful! Now, here's an awkward thing: What if the Makefile isn't named "Makefile"? Well, you specify this with -f:

make -C subproject -f Special_makefile

This means: change into the directory subproject, then run the makefile subproject/Special_makefile. Okay, that's a little confusing. But it gets more confusing— you can actually say something like:

make -C subproject -f buildfiles/Makefile

This means: Move into the directory subproject, then run subproject/buildfiles/Makefile. In other words, the Makefile is in the subproject/buildfiles directory, but it describes how to make files that are just in subproject. That's even more confusing, but I guess I see why someone would want it. I guess.

Anyway.

I am writing a make clone. I want an "import" command in it. Often when you're using make, you'll have a directory tree like

Makefile
subproject/
    Makefile

And the top level Makefile, inside of it, will say make -C subproject. In other words, make calls itself. This sorta makes sense cuz it lets you make sort of a tree of Makefiles, and each directory has its own makefile that only knows about that directory and not the rest of your project, so you have encapsulation and that is nice. But, make calling itself is actually sort of a bad thing for various reasons. So I want this feature where instead, you would just have this line in your top level Makefile:

import subproject

and it'll find subproject/Makefile, and all the targets in subproject/Makefile will be magically sucked in to your toplevel Makefile. I think that would be neat. I'm doing this.

BUT!

I start to wonder: What if you have a subdirectory you want to import, but the file isn't named Makefile? Well… I guess I could also support

import subproject/Special_makefile

And it would just figure out if the path you gave is a file or a directory, and if it's a directory it looks for Makefile, and if it's a file it just moves into subproject and runs Special_makefile from there.

But-- Oh no. What if they did something ridiculous like put the subdirectory-logical Makefile in a sub-subdirectory, like with the confusing subproject/buildfiles/Makefile? Well, I could support:

import subproject file buildfiles/Makefile

That would be like make -C subproject -f buildfiles/Makefile, right? Gosh, it's ugly though. So I don't want to make you use it. Like, if you had to say import subproject file Special_makefile, that would be awful. So I'd have to make it be an option.

Which means I guess now I'm at a point where you can say any of:

import subproject
import subproject/Makefile
import subproject file Makefile

and all three of these mean the exact same thing.

So.

1. Is this confusing? Having three ways of doing the same thing, I mean.
2. if saying import x/y has this magical property of figuring out if y is a directory or a file... then maybe normal 'ol make -C should be able to do that too?? Like, would it be cool or obnoxious if saying make -C subproject/Special_makefile were a synonym for make -C subproject -f Special_makefile???
3. Should I just friggin drop the -f feature from the command line and the file extension from import? Are these actually useful for anyone?? If I take them out, that would meanmeans that your Makefile, whatever it's named, has to be located in the directory of the files it's building.