PiDP-8/I SoftwareForum
Not logged in

Use of "bin" in Makefile.in

(1) By poetnerd on 2018-10-07 16:07:43 [link]

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.

(2) By tangent on 2018-10-07 17:42:43 [link] in reply to 1

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.

(3) By poetnerd on 2018-10-07 20:46:46 [link] in reply to 2

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.

(4) By tangent on 2018-10-08 00:09:39 in reply to 3

You can do that with Autosetup as well:

$ mkdir build           # relative to checkout directory
$ cd build
$ ../configure --args --here

There's a fair chance that won't work in your branch due to changes you've made there. It requires careful handling in the Makefile, so if you don't do it regularly, it's the sort of thing that can bit rot.

If you see me making changes related to "out of tree builds", that's what it means.