Several Darwin quartz objects not being built when using GNU make-3.81+.

Hi,


(This is part of a collection of patches and workarounds I have
for consideration for problems in the build process in current
cvs.  I'll just briefly describe each patch(-set) below, and if
needed will put them into bugzilla separately with more details.)


6.  Several Darwin quartz objects not being built when using GNU
make-3.81+.


Build Log snip:

>>>>
[...]  -Wall -UNEED_SCREEN_REGIONS     -I. -I../../../../../programs/Xserver/fb -I../../../../../programs/Xserver/mi -I../../../../../programs/Xserver/include            -I../../../../../programs/Xserver/render -I../../../../../programs/Xserver/miext/shadow            -I../../../../../programs/Xserver/Xext -I.. -I../../../../../lib/apple  -I../../../../../exports/include    -D__powerpc__ -D__DARWIN__                                 -DNO_ALLOCA -DCSRG_BASED  -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP 	-DXCSECURITY -DXSYNC -DXF86BIGFONT 	 -DBIGREQS -DPANORAMIX -DRENDER -DRANDR 	-DRES  -DPIXPRIV 	  		      -DNDEBUG  		       -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH 				 -DXFree86Server 				-DSMART_SCHEDULE 				-DBUILDDEBUG 				-DX_BYTE_ORDER=X_BIG_ENDIAN      -DXBINDIR=/usr/X11R6/bin -DXINITDIR=/usr/X11R6/lib/X11/xinit           -DHAS_CG_MACH_PORT -DROOTLESSDEBUG -DBUILD_XPR -DHAS_KL_API   pseudoramiX.c
rm -f libXQuartz.a
ar clq libXQuartz.a Preferences.o         XApplication.o         XServer.o         applewm.o         keysym2ucs.o         quartz.o         quartzAudio.o         quartzCocoa.o         quartzPasteboard.o         quartzKeyboard.o         quartzStartup.o         pseudoramiX.o
ar: Preferences.o: No such file or directory
ar: XApplication.o: No such file or directory
ar: XServer.o: No such file or directory
ar: quartzCocoa.o: No such file or directory
make[6]: *** [libXQuartz.a] Error 1
make[6]: Leaving directory `/Volumes/Biggie/test/xf86_cvs/build/programs/Xserver/hw/darwin/quartz'
[...]
<<<<

...and at least the cr/ subdir under quartz/ is doing similar, too.

There is nothing in the log that shows these objects were built at
all, period.

To recreate:

a)  Build and install GNU make-3.81 release or from cvs/svn. 
Be sure to adjust $PATH etc. properly if needed.
I'm presently using:
$ make --version
GNU Make 3.81.90
[...]
This program built for powerpc-apple-darwin8.9.0

b)  Build xf86 with latest XCode (Apple-provided gcc, ld, etc.).

c)  Possibly related env-vars:
export MACOSX_DEPLOYMENT_TARGET="10.4"
export SDKROOT="/Developer/SDKs/MacOSX10.4u.sdk"
export SDK="${SDKROOT}"
...and maybe others...

$ gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5367)
[...]

$ uname -a
Darwin <hostname> 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22 20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh powerpc PowerMac7,3 Darwin

(OSX 10.4.9 running on a Dual G5 2.7GHz with 3.5GB of matched-pair
SDRAM and more...)


Discussion:

GNU-make versions starting with 3.81 (and still in CVS as I write
this) do not see the rules for building .m files (Objective-C for
MacOSX).  This actually occurs on many different projects around
the world (I first noticed on MPlayer).  I don't know how to fix
this in Makefiles; I don't see any indication that the make-devel
list or their bugtracker even know about this problem, so I
surmise we're not doing something right with the vastly revamped
GNU-make versions.  One must use Apple's provided gnumake (3.80)
to compile these modules.  So when using make-3.81+ and the build
stops as above, I do this:
$ cd [build/]programs/Xserver/hw/darwin/quartz
$ gnumake
$ cd [build/]programs/Xserver/hw/darwin/quartz/cr
$ gnumake
... then cd back to the [build] dir and continue with using GNU
make-3.81+ (which is named 'make', lives in /usr/local/bin, and
$PATH hits it first).


Thanks for any help.  :)