Something I'm used to with UNIX/Linux is to be able to name a particular target file in a command line run of Make to rebuild just that target.

The way Makefile.in is structured, many targets have a hard coded "bin/" in front of the name, instead of a variable.

I would like to understand the rationale for structuring Makefile.in this way.

Would it be cleaner to have destination directories specified in varibles?

$BUILDBIN

$BUILDLIB

occur to me.

I think you've got two orthogonal requests here:

1. Don't hardcode bin/.

   My answer: if you have some specific need for a single variable that you can override to put what currently lands in bin elsewhere, by all means, check in a change that allows it.

   Note that this would go on trunk or a new branch, depending on whether you can do it in a single checkin or not. Don't hide it away on your V3F branch. If you want it on the V3F branch, you'd merge trunk up into your branch as we've discussed previously.

2. Allow e.g. "make foo" without a path.

   My answer: I don't see how solving problem #1 gets you this. I think that with $BIN or whatever, you still need to say "make bin/foo", because $BIN still expands to bin by default after that change.

   I suspect if you think about other software projects where you've been able to build individual targets without giving a path, they're set up to drop all build products into the top level of the build directory. (Or, they've got a recursive build system, and the top-level Makefile is just calling "cd bar ; make foo" or similar.)

   That then gets to your "why" question: because I don't like littering the top level of my build directory with output files.

As I think of it, the build trees I’m used to build into the current working directory, and things are kept out of the source tree by having the build tree be a symbolic link farm back to the source tree.

At this point, no change seems warranted.

Thanks for clarifying.