[prev in list] [next in list] [prev in thread] [next in thread]
List: xfree86-devel
Subject: Re: Several Darwin quartz objects not being built when using GNU
From: SciFi <sci-fi () hush ! ai>
Date: 2007-04-22 17:27:25
Message-ID: f0g5tt$ntv$1 () sea ! gmane ! org
[Download RAW message or body]
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@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic