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

On Fri, 20 Apr 2007, SciFi wrote:

> I've come across a bug filed a year ago with the GNU make project here:
> <https://savannah.gnu.org/bugs/index.php?16389>
> 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.