[FFmpeg-cvslog] r14143 - in trunk: common.mak configure

[Diego Biurrun]

On Sat, Jul 12, 2008 at 09:31:01PM +0100, M?ns Rullg?rd wrote:
> Diego Biurrun <diego at biurrun.de> writes:
> 
> > On Sat, Jul 12, 2008 at 05:01:54PM +0100, M?ns Rullg?rd wrote:
> >> Diego Biurrun <diego at biurrun.de> writes:
> >> 
> >> > On Wed, Jul 09, 2008 at 09:09:51PM +0200, mru wrote:
> >> >> 
> >> >> Log:
> >> >> regenerate dependencies when building object files
> >> >
> >> > Hmm...
> >> >
> >> >> --- trunk/common.mak	(original)
> >> >> +++ trunk/common.mak	Wed Jul  9 21:09:50 2008
> >> >> @@ -38,6 +38,8 @@ CFLAGS := -DHAVE_AV_CONFIG_H -D_FILE_OFF
> >> >>  
> >> >> +%.o: %.d
> >> >> +
> >> >> 
> >> >> --- trunk/configure	(original)
> >> >> +++ trunk/configure	Wed Jul  9 21:09:50 2008
> >> >> @@ -970,7 +970,7 @@ SLIBNAME_WITH_MAJOR='$(SLIBNAME).$(LIBMA
> >> >>  
> >> >>  # gcc stupidly only outputs the basename of targets with -MM
> >> >> -DEPEND_CMD='$(CC) $(CFLAGS) -MM -MG $< | sed -e "/^\#.*/d" -e "1s,^,$(@D)/," -e "s,\\([[:space:]]\\)\\(version\\.h\\),\\1\$$(BUILD_ROOT_REL)/\\2," -e "s/\(.*\)\.o/\1.d &/"'
> >> >> +DEPEND_CMD='$(CC) $(CFLAGS) -MM -MG $< | sed -e "/^\#.*/d" -e "1s,^,$(@D)/," -e "s,\\([[:space:]]\\)\\(version\\.h\\),\\1\$$(BUILD_ROOT_REL)/\\2,"'
> >> >
> >> > Uoti just confirmed my initial suspicion after I ported this over
> >> > to MPlayer: This change is not equivalent.
> >> >
> >> > The reason I made this change in the first place was to have .d files
> >> > updated when any of the files the .c file depends on changes.  This was
> >> > to reflect changing header inclusions, etc.  This no longer works.  Try
> >> > touching a header file and running make, .d files will not get updated
> >> > even though they could be affected.
> >> 
> >> I realised this later.  The problem is that, as it was, removing a
> >> header file totally confused make into not even trying rebuild the
> >> object file, and people were complaining about that.
> >
> > Elaborate, what scenario exactly is causing problems?
> 
> Delete any header file, and try to make an object file that depends on
> it.

I think an explicit error is preferable to a silent miscompilation.  I'm
in favor of reverting this.

Diego