Re: [PATCH] Makefile: Improve compiler header dependency check

From: David Aguilar <davvid@gmail.com>
Date: Aug 27, 2011, 21:19 UTC
Message-ID: <20110827211958.GA45286@gmail.com>
In-Reply-To: <20110827162645.GA10476@elie.gateway.2wire.net>

On Sat, Aug 27, 2011 at 11:26:54AM -0500, Jonathan Nieder wrote:

Show 21 quoted lines

> David Aguilar wrote:
> 
> > I fired up git's next branch on a mac laptop where I
> > have a config.mak that builds universal git binaries:
> >
> > CFLAGS = -arch i386 -arch x86_64
> >
> > This configuration broke when 111ee18c31f9bac9436426399355facc79238566
> > was merged into next.
> 
> Good catch; thanks.  This information would be useful for the commit
> message.
> 
> > gcc cannot generate header dependencies when
> > multiple -arch statements are used
> 
> Sounds like a bug.  Any idea why it behaves that way?  What error message
> does it write?
> 
> If it is a bug, it might be worth reporting this to the gcc devs while
> at it.

This has been the behavior for as long as I can remember. I don't think it's a bug. I included the error message in the commit message for [PATCH v2]:

	gcc-4.2: -E, -S, -save-temps and -M options are
	not allowed with multiple -arch flags

I don't think it's a gcc bug. This is just another one of those annoying mac-isms. When building against multiple archs gcc will include a different set of headers for each arch which is likely why the gcc devs do not support it.

I sent a v2 version of the patch that uses $(SHELL_PATH) and omits $(EXTRA_CPPFLAGS).

I think the ideal situation would be for the dependency check to emit headers required across all architectures but that's not how it works. Perhaps there are some internal architectural limitations in gcc that prevent it from being done that way.

My experience has been that most projects DTRT when CFLAGS is configured this way. It's always one or two that require intrusive Makefile or libtool hacks to make them build universal and those are no fun ;-)

BTW after applying this patch I immediately ran into the compat/obstack.[ch] portability problem that I responded to in another thread. I was finally able to make git build with the patch that I included inline there but I think it still needs work. I'll keep an eye on that thread so that we can get a final patch for it.

I also noticed that a few of our compat/ files have gcc/autoconf-isms such as:

#ifdef HAVE_CONFIG_H #include "config.h" #endif

Should I clean these up?  They seem unnecessary.

-- 
					David