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: >> <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. 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 bugs. You're setting a good mark for other projects to match. :) _______________________________________________ Devel mailing list Devel@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/devel
