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?
occur to me.
I think you've got two orthogonal requests here:
My answer: if you have some specific need for a single variable that you can override to put what currently lands in
binelsewhere, 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.
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
$BINor whatever, you still need to say "
make bin/foo", because
$BINstill expands to
binby 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.
(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.