Marc Aurele La France
Sun, 22 Apr 2007 09:44:05 -0700
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. _______________________________________________ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel