bugmake - Bugs: bug #16389, Defaults for Objective-C

 
 

bug #16389: Defaults for Objective-C

Submitter:  None
Submitted:  Thu 20 Apr 2006 03:56:29 AM UTC
Votes: 11
 
Severity:  3 - Normal Item Group:  Enhancement
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  4.0 Operating System:  Any
Fixed Release:  3.82 Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 11 May 2007 07:39:39 PM UTC, comment #8: 

I added most of these rules.  One thing I didn't add was the default variable setting "OBJCFLAGS = $(CFLAGS)".  That doesn't seem right to me; we don't do that with C++ for example.  However, I don't program in objective C so maybe I'm just missing something.  Let me know.

Paul D. Smith <psmith>
Group administrator
Tue 01 May 2007 04:21:42 AM UTC, comment #7: 

Icarus: I'm sorry you feel frustrated about the situation.  However, I'm not going to discuss it in bug report comments: that's not appropriate.  If you want to talk about it you can use one of the public mailing lists, or email me and/or Boris and/or RMS and/or anyone else you like directly, or even use the make-alpha list or one of the GNU project mailing lists, depending on the audience you'd like to contact.

Please keep the bug report comments for discussion on the bugs in the report.  Thanks!

Paul D. Smith <psmith>
Group administrator
Tue 01 May 2007 01:25:12 AM UTC, comment #6: 

Perhaps it is time to consider forking GNU make?
The current maintainer seems too busy to give it the attention it deserves, but appears unwilling to allow others to help.

If we look at CVS, we see a burst of activity on March 19th, with a small fixup on the 21st. Prior to that the last checkin was November 18th of last year, and before that was the end of September, and then some at the start of April. So 4 checkins in the last 12 months.

In this time crippling bugs have been reported, and in some cases patches submitted, but are still not available even via CVS. Paul says that a new version will not be out for "months".

Paul seems to have some interesting projects in the works, in particular adding Guile to make, but I think users deserve to have access to the best bug free product the community can currently build. It took 3.5 years to go from 3.80 to 3.81, will we need to wait until 2010 before we see 3.82?

Icarus Sparry <icarus>
Fri 20 Apr 2007 04:40:49 PM UTC, comment #5: 


> why not just add the rules into your makefile if you need them?


  Not easy to do if you're talking about a large number of projects.

> I do realize this means that any makefile that uses objective-C
> needs to be changed, but the same is true for any number of
> other languages that make doesn't provide default rules for.


  Obj-C is provided by GNU CC.  It makes sense for GNU Make to provide builtin support for the entire family of languages supported by GNU CC.

> Further, even if we do change this for the next release of GNU
> make that won't be out for some months, then it will be many
> months more before that version is considered wide spread


  That's a problem for end users and distro creators, not for the GNU Make maintainer; they can all deal with it however they wish, but adding the patch gives them the option.

> And finally, of course, requiring default rules just means
> makefiles are even more tightly tied to GNU make


  I don't think this is a real problem either.  Anyone who is building ObjC is almost certainly using Gnu Make.  After all, this would be a reason to remove all the string functions and other GNU-specific features, but in fact, it is not GNU Make's purpose to be a subset of all other make implementations; it intends to be standardised enough to correctly process non-GNU makefiles, while adding enhancements useful to support the technical and political goals of the GNU project.

  I vote for acceptance.

Dave Korn <davek>
Fri 20 Apr 2007 04:19:54 PM UTC, comment #4: 


Paul,

You repeated what I said already -- because we'd need to add obj-c rules to every affected project.  Apple already depends on GNU make to this degree.  So far every such project "assumes" the buildbots will be using Apple make -- let's not call it GNU make from this point on just so I can show you how restrictive this assumption is!

Do you really want to cause the buildbots that run on every-other platform to apply non-GNU-sanctioned patches onto their source trees just for sakes of cross-building?

Let's make a decision here, please.  Either accept this patch (or a suitable reworked version if needed) -or- please close this bug with e.g. "WONTFIX" so I can take this official answer to the other affected projects and urge them to do the inevitable.  I can't do the latter with much muscle if this bug is kept open.  Sorry to put it this strongly but I'm tired of fighting these kinds of spats between projects.  I do this for therapy and for fun, not for pay or the like.  ;)

Please decide.

Thank you.


SciFi <scifi>
Wed 18 Apr 2007 03:29:03 PM UTC, comment #3: 

I agree with Paul pretty much, however, this patch has been waiting here for quite a while with no real reason, IMO, for not adding it. Being a GNU make only feature is not really an issue, I don't think, there are a whole bunch of GNU make only features :-)

I would really appreciate it if this patch (or something similar) could be committed fairly soon.

Thank you,
Peter

Peter O'Gorman <pogma>
Wed 18 Apr 2007 01:28:13 PM UTC, comment #2: 

I don't really understand the urgency around this: why not just add the rules into your makefile if you need them?  The built-in rules are just that: built-in; they can be added to or removed in makefiles.

I do realize this means that any makefile that uses objective-C needs to be changed, but the same is true for any number of other languages that make doesn't provide default rules for.

Further, even if we do change this for the next release of GNU make that won't be out for some months, then it will be many months more before that version is considered wide spread (I know of distros that still ship GNU make 3.79.1, and MANY that still use 3.80 more than a year after 3.81 was released).

And finally, of course, requiring default rules just means makefiles are even more tightly tied to GNU make (since no other make provides these default rules as far as I know).

Paul D. Smith <psmith>
Group administrator
Wed 18 Apr 2007 01:08:49 PM UTC, comment #1: 


Hi,

I wish I had seen this report last year.  Just about every project around the world that needs to compile .m objects is needing this patch.

  •  The XFree86 project's darwin support can't be built with make-3.81[.90cvs].  This patch is required to do so -or- one must use Apple's [gnu]make (3.80) which of course does have a similar patch.


  •  The MPlayer project had a revamp of its configure/makefile build system a few months ago.  They are now "assum"ing one is on an actual darwin platform in order to build the project's macosx video/audio modules.  They ditched the make-rules for .m objects completely.  Those modules cannot be built with make-3.81+ without this patch -or- one is forced to use Apple's [gnu]make as above.


  •  I've come across a few other projects that fail building without this patch, but the two mentioned above are the biggees.



I don't know how these projects will fare in the cross-build environment since non-darwin systems will be unable to use Apple's [gnu]make.  In other words, it will currently be impossible to build binaries for darwin systems if the build system is not actually running Darwin/OSX with Apple's [gnu]make.  The best way to fix the non-darwin build system is to apply this patch to its version of make(1), whether or not it is 3.81 -- otherwise, every affected project around the world will need to revamp its configure/makefile code to add these rules explicitly.

I therefore urge this project to commit this patch ASAP if it's in acceptable form right now.  If not, please let's discuss this further so we can get it into shape for committing ASAP.


Thank you very much.


SciFi <scifi>
Thu 20 Apr 2006 03:56:29 AM UTC, original submission:  

It would be good to have default rules for objective-c.
See also:http://lists.gnu.org/archive/html/bug-make/2006-04/msg00049.html

Attached is a suggested patch. Thanks.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #9806:  make_objc.patch added by None (5KiB - text/x-patch - Suggested patch to add objective-c defaults)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by icarus (Posted a comment)
  • -email is unavailable- added by davek (Posted a comment)
  • -email is unavailable- added by pogma (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by scifi (Posted a comment)
  •  

    There are 11 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-28 psmith Fixed Release4.0 3.82
    2007-05-11 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.0
    2007-04-20 davek Carbon-Copy- Added davek
    2007-04-18 scifi Carbon-Copy- Added scifi
    2006-04-20 pogma Carbon-Copy- Added -email is unavailable-
    2006-04-20 None Attached File- Added make_objc.patch, #9806

    Back to the top

    Powered by Savane 3.13-7c56.
    Corresponding source code