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

[SciFi]

On Sun, 22 Apr 2007 10:26:44 -0600, Marc Aurele La France wrote:

> On Fri, 20 Apr 2007, SciFi wrote:
> 
>> I've come across a bug filed a year ago with the GNU make project here:
>>  We're trying to
>> convince the GNU-make team to accept Apple's patches so the .m rules
>> etc. will be "implicit".  If the GNU-make team decide not to accept the
>> patch there, then we must revamp all affected projects' build systems
>> _again_ to re-insert these explicit rules.
> 
>> After logging this particular xfree86 problem, I've applied that patch
>> to my local make-3.81.90cvs so I could continue building other projects
>> (that patch indeed does help a _lot_ ;) ).  I've yet to rebuild
>> xfree86-cvs to see if that patch will help this situation, but I have a
>> strong feeling it will.
> 
>> In order to test your patch fairly, I'll need to back-out the patch to
>> make.
> 
> Not really.  You can build with gnumake instead of make.

I think the point is being misunderstood despite my trying to
explain it as carefully as I can.  ~sigh~

$ which gnumake
/usr/bin/gnumake
$ gnumake --version
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This is Apple's _modified_ make.  It has no problem with
building the darwin components.  But it's very back-level.

There is _no_ "untouched" make that Apple provides directly. 

It looks as tho ppl using darwin/osx as a development platform
are "assuming" the Obj-C rules will exist on _all_ platforms. 
So I can see why the projects admins are sort-of blaming
Apple in this regard, altho Obj-C is not darwin-specific.

If we want the latest supported version of make, we get the
original tarballs and build it ourselves, as I have done. 
And then we find the Obj-C rules have "disappeared".


>> If I could ask anyone in the audience here interested to go to that bug
>> report for GNU make and add your comments (either 'for' or 'against'),
>> I'd appreciate it, as the GNU team really needs to make a final
>> decision.  As I mention there-in, if they decline, then I can pursue
>> the issue with affected projects with a stronger argument ... if they
>> leave the make bug open / undecided, I don't have much muscle.  So I'm
>> asking people to help out either way, just so we'll have a final
>> decision.  Of course several of us are very much wanting the GNU team
>> to accept the patch just so the issues can be resolved relatively
>> easily than the inevitable alternative... and please keep in mind I'm
>> more worried about buildbots that don't run on darwin/osx but must
>> build _for_ darwin/osx...
> 
> While I understand your take on this, I don't entirely agree with it. 
> It seems to me that the root cause of this is that Apple distributes a
> system including changes to free/open software that they did not bother
> to, or succeed in, pushing upstream.  In the first case, accepting the
> change referenced in the bug report now would mean GNU sanctions such
> behaviour.

Together with my reply to the GNU-make bug report there, I
opened a similar bug report with the MPlayer project (FFmpeg is
unaffected by this situation).  In both I am reminding ppl that
we are volunteers, we do this as a hobby for fun (and therapy
for me: I do have a few dozen years experience in system-level
programming and electronics).  I'm tired of all these spats
between projects like this.  It _is_ up to volunteers to pass
patches up-stream if need be -- such patches are NOT ANY LESS
valid when a volunteer does it!  And this particular patch has
been sittin' there for a year so far, and looks to be ignored
even longer.


> On a more technical level, Objective C projects need to define .m.o
> suffix rules in any case, if they are to be portable to other make
> implementations. I doubt very much all such projects are
> Darwin-specific.

A responder to that GNU-make bug report says that most likely a
programmer _is_ using GNU compilers when developing Obj-C
modules.  So GNU ought to go ahead in supporting their own
projects (products) like this.

> In any case, XFree86's dependence on this specific Apple change to GNU
> make has now been removed.

I was sure you would help, thank you.  One project down and
up-teen more to go.  ;)  I am probably going to have a fight
with the MPlayer dudes on this, tho; they don't like having to
put back in what they've ripped out of their custom scripts. 
That word "assume" -- y'know what it means...  ;)

> Marc.

I should mention we were having crazy weather and lost our
connection for most of yesterday (along with other problems). 
I've not even had a chance to test your patches.  I'll cvs-up
soon as that public server will push your changes thru (re: that
scheduling problem I mentioned here a week or so ago).

Thank you very much for your time & work in helping us fix
these b

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

[Marc Aurele La France]

On Fri, 20 Apr 2007, SciFi wrote:


I've come across a bug filed a year ago with the GNU make project here:

We're trying to convince the GNU-make team to accept Apple's patches
so the .m rules etc. will be "implicit".  If the GNU-make team decide
not to accept the patch there, then we must revamp all affected
projects' build systems _again_ to re-insert these explicit rules.



After logging this particular xfree86 problem, I've applied that
patch to my local make-3.81.90cvs so I could continue building other
projects (that patch indeed does help a _lot_ ;) ).  I've yet to
rebuild xfree86-cvs to see if that patch will help this situation,
but I have a strong feeling it will.



In order to test your patch fairly, I'll need to back-out the patch
to make.


Not really.  You can build with gnumake instead of make.


If I could ask anyone in the audience here interested to go to that
bug report for GNU make and add your comments (either 'for' or
'against'), I'd appreciate it, as the GNU team really needs to make a
final decision.  As I mention there-in, if they decline, then I can
pursue the issue with affected projects with a stronger argument ...
if they leave the make bug open / undecided, I don't have much
muscle.  So I'm asking people to help out either way, just so we'll
have a final decision.  Of course several of us are very much wanting
the GNU team to accept the patch just so the issues can be resolved
relatively easily than the inevitable alternative... and please keep
in mind I'm more worried about buildbots that don't run on darwin/osx
but must build _for_ darwin/osx...


While I understand your take on this, I don't entirely agree with it.  It 
seems to me that the root cause of this is that Apple distributes a system 
including changes to free/open software that they did not bother to, or 
succeed in, pushing upstream.  In the first case, accepting the change 
referenced in the bug report now would mean GNU sanctions such behaviour.


On a more technical level, Objective C projects need to define .m.o suffix 
rules in any case, if they are to be portable to other make implementations. 
I doubt very much all such projects are Darwin-specific.


In any case, XFree86's dependence on this specific Apple change to GNU make 
has now been removed.


Marc.

+--+--+
|  Marc Aurele La France   |  work:   1-780-492-9310  |
|  Academic Information and|  fax:1-780-492-1729  |
|Communications Technologies   |  email:  [EMAIL PROTECTED] |
|  352 General Services Building   +--+
|  University of Alberta   |  |
|  Edmonton, Alberta   |Standard disclaimers apply|
|  T6G 2H1 |  |
|  CANADA  |  |
+--+--+
XFree86 developer and VP.  ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

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

[SciFi]

Hi,

I've come across a bug filed a year ago with the GNU make project here:

We're trying to convince the GNU-make team to accept Apple's patches
so the .m rules etc. will be "implicit".  If the GNU-make team decide
not to accept the patch there, then we must revamp all affected
projects' build systems _again_ to re-insert these explicit rules.


After logging this particular xfree86 problem, I've applied that
patch to my local make-3.81.90cvs so I could continue building other
projects (that patch indeed does help a _lot_ ;) ).  I've yet to
rebuild xfree86-cvs to see if that patch will help this situation,
but I have a strong feeling it will.

In order to test your patch fairly, I'll need to back-out the patch
to make.

If I could ask anyone in the audience here interested to go to that
bug report for GNU make and add your comments (either 'for' or
'against'), I'd appreciate it, as the GNU team really needs to make a
final decision.  As I mention there-in, if they decline, then I can
pursue the issue with affected projects with a stronger argument ...
if they leave the make bug open / undecided, I don't have much
muscle.  So I'm asking people to help out either way, just so we'll
have a final decision.  Of course several of us are very much wanting
the GNU team to accept the patch just so the issues can be resolved
relatively easily than the inevitable alternative... and please keep
in mind I'm more worried about buildbots that don't run on darwin/osx
but must build _for_ darwin/osx...

Thank you.


___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel

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

[Marc Aurele La France]

On Wed, 11 Apr 2007, SciFi wrote:


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  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).


Does the patch below help?

*** cvs/xc/config/cf/Imake.tmpl Sun Apr  1 18:33:28 2007
--- devel/xc/config/cf/Imake.tmpl   Sat Apr 14 23:40:09 2007
*** XCOMM common rules for all Makefiles - d
*** 2255,2260 
--- 2255,2265 
  .cc.s:
CompileCplusplusToAsm($(_NOOP_))

+ .SUFFIXES: .m
+
+ .m.o:
+   $(CC) -c $(CFLAGS) -o $@ $<
+
  /*
   * These need to be here so that rules in Imakefile occur first;  the blank
   * emptyrule is to make sure that an empty Imakefile does not default to make

Thanks.

Marc.

+--+--+
|  Marc Aurele La France   |  work:   1-780-492-9310  |
|  Academic Information and|  fax:1-780-492-1729  |
|Communications Technologies   |  email:  [EMAIL PROTECTED] |
|  352 General Services Building   +--+
|  University of Alberta   |  |
|  Edmonton, Alberta   |Standard disclaimers apply|
|  T6G 2H1 |  |
|  CANADA  |  |
+---

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

[SciFi]

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  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.  :)


___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel