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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:  tsi@xxxxxxxxxxx         |
|  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@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [X Forum]     [XFree86]     [XFree86 Newbie]     [X.Org]     [IETF Annouce]     [Security]     [Fontconfig]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux