Hi On Mon, Sep 9, 2013 at 1:43 PM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > On Mon, Sep 09, 2013 at 12:48:08PM +0200, David Herrmann wrote: >> Hi >> >> On Mon, Sep 9, 2013 at 12:27 PM, Thierry Reding >> <thierry.reding@xxxxxxxxx> wrote: >> > The genshader and genunifont utilities are run during the build process >> > to generate source files. In order for that to work when cross-compiling >> > the files need to be built using the native compiler instead of the >> > cross-compiler. >> > >> > Add the AX_PROG_CC_FOR_BUILD m4 macro which defines various *_FOR_BUILD >> > variables that are the native equivalents of CC, CFLAGS, LDFLAGS, etc. >> > Override CC, CFLAGS and LDFLAGS for genshader and genunifont and their >> > object files so that they will be built natively and can be executed >> > during the build. >> >> Thanks a lot! Looks all good, few comments below. I think I will apply >> it as is, anyway. New bugfix-release is planned for this week, too. >> >> > Signed-off-by: Thierry Reding <treding@xxxxxxxxxx> >> > --- >> > Makefile.am | 16 ++++-- >> > configure.ac | 3 +- >> > m4/ax_prog_cc_for_build.m4 | 125 +++++++++++++++++++++++++++++++++++++++++++++ >> > 3 files changed, 139 insertions(+), 5 deletions(-) >> > create mode 100644 m4/ax_prog_cc_for_build.m4 >> > >> > diff --git a/Makefile.am b/Makefile.am >> > index 7019290..f1b4435 100644 >> > --- a/Makefile.am >> > +++ b/Makefile.am >> > @@ -445,8 +445,12 @@ EXTRA_DIST += $(SHADERS) >> > CLEANFILES += src/static_shaders.c >> > genshader_SOURCES = src/genshader.c >> > >> > -src/static_shaders.c: $(SHADERS) genshader$(EXEEXT) >> > - $(AM_V_GEN)./genshader$(EXEEXT) src/static_shaders.c $(SHADERS) >> > +src/static_shaders.c: $(SHADERS) genshader$(BUILD_EXEEXT) >> > + $(AM_V_GEN)./genshader$(BUILD_EXEEXT) src/static_shaders.c $(SHADERS) >> > + >> > +genshader$(BUILD_EXEEXT) $(genshader_OBJECTS): CC = $(CC_FOR_BUILD) >> > +genshader$(BUILD_EXEEXT) $(genshader_OBJECTS): CFLAGS = $(CFLAGS_FOR_BUILD) >> > +genshader$(BUILD_EXEEXT): LDFLAGS = $(LDFLAGS_FOR_BUILD) >> >> Just wondering, isn't this going to break if $BUILD_EXEEXT != $EXEEXT >> I mean, noinst_PROGRAMS generates build-rules for $EXEEXT, not for >> $BUILD_EXEEXT, so a dependency on "genshader$(BUILD_EXEEXT)" won't do >> anything if it differs from $EXEEXT. But maybe I am just missing >> something and automake creates rules for both? > > That's a good point. And yes, I think it would break if both extensions > differed. On the other hand I have no idea on how to make automake > generate rules for $(BUILD_EXEEXT). I don't think it can. > > Interestingly, I mistakenly used genshader$(EXEEXT) initially, but that > causes automake to spew out warnings that these "rules" (which aren't > really rules at all) were overriding previous commands for the same > target. So while $(BUILD_EXEEXT) is the right extension to use, it also > works around a shortcoming in automake. Another shortcoming of automake > will cause this to break when doing MinGW->Unix and Unix->MinGW cross- > builds... > > A different approach of this patch was to move genshader and genunifont > to a tools subdirectory with a separate Makefile.am and overwrite the > CC, CFLAGS and LDFLAGS variables in that directory only, but automake > doesn't accept that either because CFLAGS is considered a user variable > and therefore can't be overwritten. > > I think this is as good as it gets for now. I've tried to fix this kind > of problem in automake several times but never managed to. Perhaps it's > time to move on to something like SCons... Yepp, automake has issues but it's still better than the alternatives, imho. Patch is applied and pushed. I only added a small TODO-comment so I don't forget about this issue. I don't have any better idea right now. Btw., there's kmscon-devel@lists.<fdo> (which is an open list and doesn't require registration). Thanks David _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel