Out of curiosity: how exactly does this help with cross-compilation?

It's a reasonable thing to ask to be able to override the tools I guess, I'm just not sure I understand how it helps. You'd usually want to use the tools on the host system not the target, wouldn't you? Is this to point it to tools on the host that aren't in the PATH?

Exactly, that is to work around a PATH problem.
When cross compiling you often end up with you target $(sysroot)/usr/bin in PATH and therefore configure picks glib-* tools compiled for arm instead of the native sysroot (or system) path to glib-* tools.
Obviously you can't execute any arm compiled binary on you x86 system.

I know Buildroot for example uses this kind of tricks sometimes : http://git.buildroot.org/buildroot/tree/package/libglib2/libglib2.mk#n43

I guess OpenEmbedded/Yocto does the same thing.

Thanks for the explanation.

Why would one end up with the $target/usr/bin in PATH though? That just sounds odd to me.


> I know Buildroot for example uses this kind of tricks sometimes :
> http://git.buildroot.org/buildroot/tree/package/libglib2/libglib2.mk#n43

In there it does:

  ac_cv_path_GLIB_GENMARSHAL=$(HOST_DIR)/usr/bin/glib-genmarshal

That won't affect the paths set like in the patch though, will it? (But you just want the ability to override them somehow, right?)

One of the reason you would end up with $target/usr/bin in PATH is that you're "lazy" and don't want to recompile the whole stack twice (one native, one target). That's the approach taken by buildroot for example, they want to reduce the build time as much as possible. In this case there are a few script in $target/usr/bin that you can use (mostly perl/shell).

In my case I'm cross compiling (static compilation) with jhbuild for android. The idea is to avoid to generate Android.mk files for every single package I'm going to need in my app, and just compile the whole thing as I would do for a normal jhbuild setup. And then just use the generated .a libraries in my android app.

ac_cv_path_GLIB_GENMARSHAL=$(HOST_DIR)/usr/bin/glib-genmarshal will affect detection of glib-genmarshal. Basically autoconf allows you to force the result of some checks, in this case it avoids looking for glib-genmarshal in PATH and instead takes the value you've given in the environment.

> ac_cv_path_GLIB_GENMARSHAL=$(HOST_DIR)/usr/bin/glib-genmarshal will affect
> detection of glib-genmarshal. Basically autoconf allows you to force the result
> of some checks, in this case it avoids looking for glib-genmarshal in PATH and
> instead takes the value you've given in the environment.

Yeah, I'm aware of how that is supposed to work. What I meant to say is that I don't think that setting ac_cv_path_GLIB_GENMARSHAL will help in this particular case, with the patch you proposed, because ac_cv_path_FOO is only something that works if AC_PATH_PROG is used, and AM_PATH_GLIB_2_0 doesn't use AC_PATH_PROG.

But as I'd prefer to avoid using AM_PATH_GLIB_2_0 anyway, we can probably easily fix that up.

Oh sorry I mixed that with another patch, here I'm redefining pkg-config values using :


export PKG_CONFIG="pkg-config --define-variable=glib_genmarshal=/usr/bin/glib-genmarshal --define-variable=gobject_query=/usr/bin/gobject-query --define-variable=glib_mkenums=/usr/bin/glib-mkenums --define-variable=glib_compile_resources=/usr/bin/glib-compile-resources"

Created attachment 216588 [details] [review]
gst-glib.m4: check for glib-mkenums and glib-genmarshal and allow them to be overridden

Comment on attachment 215842 [details] [review]
Patch v1

Partially committed:


commit a30e63740644179aab267c17d7748333f6d7ae2c
Author: Lionel Landwerlin <llandwerlin@gmail.com>
Date:   Thu Aug 23 13:51:27 2012 +0100

    gst: use configure-detected or externally provided glib-mkenums
    
    To ease cross-compilation.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=677620

This was pushed to master a while back.