Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Oct 2004 08:50:29 +0200 (CEST)
From:      Harti Brandt <harti@freebsd.org>
To:        Dan Strick <strick@covad.net>
Cc:        dan@mist.nodomain
Subject:   Re: questionable feature in FreeBSD pmake
Message-ID:  <20041029084715.C52069@beagle.kn.op.dlr.de>
In-Reply-To: <200410281201.i9SC1Vk8002007@mist.nodomain>
References:  <200410281201.i9SC1Vk8002007@mist.nodomain>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 Oct 2004, Dan Strick wrote:

DS>On Thu, 28 Oct 2004 03:23:02 -0700, I wrote:
DS>>
DS>> I just spent a *very* frustrating hour trying to figure out why the
DS>> FreeBSD make program was invoking all commands to make things in a
DS>> subdirectory named "obj".  I eventually discovered this gem in the
DS>> make man page:
DS>>
DS>>     In addition, make sets or knows about the following internal
DS>>     variables or environment variables:
DS>>
DS>>     ...
DS>>
DS>>     .OBJDIR	A path to the directory where the targets are built.  At
DS>> 		startup, make searches for an alternate directory to place
DS>> 		target files.  It will attempt to change into this special
DS>> 		directory and will search this directory for
DS>> 		found in the current directory.  The following directories
DS>> 		are tried in order:
DS>>
DS>> 		1.   ${MAKEOBJDIRPREFIX}/`pwd`
DS>> 		2.   ${MAKEOBJDIR}
DS>> 		3.   obj.${MACHINE}
DS>> 		4.   obj
DS>> 		5.   /usr/obj/`pwd`
DS>>	...
DS>>
DS>
DS>A little while later Peter Pentchev responded:
DS>>
DS>> Actually, this feature lies at the base of the FreeBSD base system build
DS>> infrastructure, and it is pretty much The Feature that allows us to
DS>> build from read-only and/or NFS-mounted sources shared among wide swarms
DS>> of machines :)
DS>>
DS>and
DS>>
DS>> Oh, and let's not forget cross-platform builds, too.
DS>>
DS>
DS>It is clear that a great deal of current FreeBSD OS makefile practice
DS>depends on the feature.  The tragedy is that it was never necessary to
DS>make the feature unavoidable.  Its invocation should have been dependent
DS>on using a special environment variable or make command option or makefile
DS>command or makefile variable.  Unfortunately, it seems that its invocation
DS>depends only on the presence of a subdirectory named "obj" in the directory
DS>in which the make command is invoked and there is NO WAY to avoid it.
DS>There seems to be absolutely nothing that I can put in my makefile to
DS>turn the feature off or to undo its effect.

I think this should be made conditional on the .POSIX target in the 
makefile. This way we don't loose this feature for system build but make 
our make more useable for outside packages. I have not yet looked into 
this.

harti

DS>
DS>It seems that I have no alternative but to rename my "obj" directory.
DS>Can someone suggest an alternative?  Note that it is not possible for me
DS>to set an environment variable (i.e. MAKEOBJDIR) before running make or
DS>to add an option to the make command line.  Any fix must be contained
DS>entirely within the makefile.  Setting .OBJDIR or MAKEOBJDIR within the
DS>makefile does not work.  Placing a "cd .." or "cd $(.CURDIR)" in front of
DS>every set of makefile shell commands is unthinkable.
DS>
DS>Dan Strick
DS>strick@covad.net
DS>
DS>(now *immensely* frustrated)
DS>_______________________________________________
DS>freebsd-hackers@freebsd.org mailing list
DS>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
DS>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
DS>
DS>
DS>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041029084715.C52069>