All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] Allow kmscon to be cross-compiled
Date: Mon, 9 Sep 2013 13:43:19 +0200	[thread overview]
Message-ID: <20130909114318.GA22197@ulmo> (raw)
In-Reply-To: <CANq1E4Sk7KY1hdLDXudaZqJgvDjCwzDv_NUXQCtLPkDsVBd1ZQ@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3534 bytes --]

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@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@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...

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2013-09-09 11:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-09 10:27 [PATCH] Allow kmscon to be cross-compiled Thierry Reding
2013-09-09 10:48 ` David Herrmann
2013-09-09 11:43   ` Thierry Reding [this message]
2013-09-12 11:41     ` David Herrmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130909114318.GA22197@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=dh.herrmann@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.