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!

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

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

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.