[PATCH] Allow kmscon to be cross-compiled

David Herrmann dh.herrmann at gmail.com
Thu Sep 12 04:41:23 PDT 2013


Hi

On Mon, Sep 9, 2013 at 1:43 PM, Thierry Reding <thierry.reding at gmail.com> 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 at gmail.com> 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 at nvidia.com>
>> > ---
>> >  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 at lists.<fdo> (which is an open list and
doesn't require registration).

Thanks
David


More information about the dri-devel mailing list