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