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

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