At Thu, 30 Jan 2025 09:00:06 +0000, David Holland <dholland-tech%netbsd.org@localhost> wrote: Subject: Re: variable MAKEOBJDIR inside of Makefile > > On Sun, Jan 26, 2025 at 12:30:19PM -0500, Mouse wrote: > > >> Only way which I found functional was using MAKEOBJDIR on commane > > >> line: [...] When I try to define it inside of Makefile then it is > > >> ignored > > > > > It's a feature. See make(1), search for .OBJDIR in the section > > > "Additional built-in variables". > > > > Okay, it's deliberate, but how is it a feature? I can't see any value > > in ignoring an in-Makefile setting of MAKEOBJDIR - what am I missing? > > Everything about make's magic objdir behavior is a bug. Indeed, but I think the problem is in implementing a feature like .OBJDIR support in any way that is sufficiently simple for a human programmer to understand and manage. One need only compare with VPATH support in GNU Make to see what a maze of twisted complexity can be created. At least with BSD Make one doesn't have to pollute the build directory with a symlink back to the Makefile in the source directory, or alternately manually remember to cd to the build directory and point make back at the Makefile where one just came from. Either way there's a bit of a chicken and egg problem, and in BSD Make, given how it .OBJDIR implemented with chdir(2) I think things just get too complicated if the location is defined inside of a Makefile. For anyone (such as myself!) trying to use "BSD Make" portably between different BSD variants w.r.t. using MAKEOBJDIR the problem has only become more complex as there is a growing discrepancy between the make implementations in each variant. I've tried to avoid recommending use of MAKEOBJDIR for my projects and instead I recommend only using MAKEOBJDIRPREFIX, which is also defined to only work if set in the environment (or, in more recent versions, on the command line). MAKEOBJDIR behaviour just differs too much between variants. However OpenBSD has fouled the water more by removing MAKEOBJDIRPREFIX support entirely since 5.5 (2013/11/24) (apparently to fix some race conditions). -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpAWEa0a1ByX.pgp
Description: OpenPGP Digital Signature