On Wed, Feb 18, 2015 at 12:48:21PM +0100, Thomas Schwinge wrote:
> > --- /dev/null
> > +++ b/gcc/config/i386/t-intelmic
> > @@ -0,0 +1,9 @@
> > +mkoffload.o: $(srcdir)/config/i386/intelmic-mkoffload.c | insn-modes.h
> > + $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
> > + -I$(srcdir)/../libgomp \
> > + -DDEFAULT_REAL_TARGET_MACHINE=\"$(real_target_noncanonical)\" \
> > + -DDEFAULT_TARGET_MACHINE=\"$(target_noncanonical)\" \
> > + $< $(OUTPUT_OPTION)
> > +
> > +mkoffload$(exeext): mkoffload.o collect-utils.o libcommon-target.a
> > $(LIBIBERTY) $(LIBDEPS)
> > + $(COMPILER) -o $@ mkoffload.o collect-utils.o libcommon-target.a
> > $(LIBIBERTY) $(LIBS)
>
> What is the rationale for the insn-modes.h order-only prerequisites for
> mkoffload.o? Is this simply to get past the build issue which, for
> example, Jakub also reported for the nvptx mkoffload,
> <http://news.gmane.org/find-root.php?message_id=%3C20150217153918.GX1746%40tucnak.redhat.com%3E>
> (»missing mkoffload.o dependencies, patch attached«), or is there a
> better rationale for adding (only) this one (indirect) dependency,
> instead of listing all of the (real) dependencies? (After all, we do
> want the mkoffload executables to be rebuilt if one of their dependencies
> is updated.) (I have not yet tried to figure out how to do that.)
Perhaps if we try to
ALL_HOST_OBJS += mkoffload.o
everything would be handled fine? I mean, in that case it should
have automatic dependency on all the $(generated_files) and
additionally automatic dependencies for mkoffload.o would be sourced in from
.deps/mkoffload.Po
Jakub
