[vlc-devel] [PATCH] contrib: add a bootstrap option to allow using prebuilt packages when cross-compiling

[Alexandre Janniaux]

Hi,

On Sat, Feb 01, 2020 at 04:11:36PM +0200, Rémi Denis-Courmont wrote:
> Le samedi 1 février 2020, 14:53:09 EET Alexandre Janniaux a écrit :
> > > It's just that we never cross-compiled to a platform that uses pkg-config.
> > > Back then, the ARM Linux builds were faked as native builds using
> > > Scratchbox.
> > Just for clarifying this, my personnal opinion is based on
> > my ~whole last year porting VLC to an arm-based target,
> > which is using pkg-config.
>
> You can't have been using something that never worked, and I don't see what
> that authority argument brings here.

My point wasn't about an authority argument but to highlight
your (following there) point that yes, it works with a
correctly configured pkg-config. I've been fixing some
contribs rules for this very exact reason, like gcrypt,
gpg-error, etc, and will probably suggest many changes to
have contribs use more pkg-config-found libraries if this
change is accepted.

> Scratchbox allowed us to use pkg-config by
> pretending to build natively. There never was support for cross-compiling with
> pkg-config. Obviously, if Steve found out that it is now viable to cross-
> compile "properly" instead of using SB, then we should do just that. This
> really is just fixing a bug where contribs were rebuilding stuff that was
> already there.

Sure, having this available is needed and I totally agree
with you on this.

> (Though we might still need SB to make actual installable .deb's ?)
>
> There are no valid reasons to disable pkg-config if it is correctly set (i.e.,
> to the correct platform/directories). It won't find what's nowhere to be found.
> To take the extreme, if you wanted to compile VLC for bare (which won't work
> as is), you would anyway have the dedicated arm-none-... triplets, and you
> wouldn't hit any "wrong" packages.

For instance, I build for (linaro-)aarch64-linux-gnu which
might become the same triplet name as raspberry one day,
and have /usr/aarch64-linux-gnu/ on my machine.

In this case, you probably need a custom pkg-config script
eventually anyway (I have one with two sysroot because
contribs path is not written with the correct prefix and
bot the variables and pc_sysrootdir are wrong then, and
I didn't have time to write a proper fix for all contribs).
But as you mentioned, it needs configuration.

My point was about eliminating configuration by default so
that builds are correct by default, even if more is built.
It means that the situation where you begin working on
cross-compiling VLC is easier, and this is probably why Qt
choose to do that too, or at least what I understood from
its documentation.

If you're confident this is not needed, we can merge the
previous version and get the temperature after, but I
fear that we wouldn't get feedback because it could be less
friendly or more error-prone, or just that people feel
crosscompilation is hard anyway.

In any case, it probably needs work on the configure.ac file
so that the same PKG_CONFIG_PATH/LIBDIR/SYSROOT are used
between contribs (which will disable some contribs) and the
configure (which won't find the already-built replacement for
contribs if not configured correctly) as well as mentioning
in documentation that the two supported ways to use
pkg-config in crosscompilation are either to put .pc files
in the given hardcoded supported location or use a wrapper
to pkg-config like mentioned in autotools.io website.

Also, as I mentioned in the first part, a lot of contribs
and libraries are not using the pkg-config executable by
default, or if they do need a wrapper script (in contribs)
anyway so only setting PKG_CONFIG_* vars in config.mak might
not be enough in situation where, unlike the raspberry
build, not all contribs are available with pkg-config.

I hope this gives more context to my points, as it is not
really about solving technical issues, but only choice --
in my opinion anyway.

Regards,
--
Alexandre Janniaux
Videolabs