Cross-compiling with pkg-config

[Dan Nicholson]

Adding the list since I'm sure people here have encountered this
scenario before.

On Mon, Dec 17, 2012 at 5:06 PM, Dennis Estenson
<destenson at digitalforcetech.com> wrote:
> Hello Tollef & Dan,
>
>
>
> I appreciate everything you've done to make pkg-config what it is today. It
> is a very useful tool and I prefer it over libtool whenever I can. However,
> I do see a need for improvement where cross-compiling is an issue. In some
> cases, there is not always a single SYSROOT directory available.  Let me
> explain...
>
>
>
> In our development paradigm, we have a tree of libraries and applications
> under a root we call $PROGRAMMING. Under the $PROGRAMMING root, we may have
> a number of 3rd-party, and in-house developed libraries and applications,
> each in a certain location under this $PROGRAMMING tree. (Each location
> mirrors the respective location in our SVN repository, which helps greatly
> for scripting automatic checkouts and builds.) When we build a library using
> our build scripts, it builds the library and "installs" it locally in the
> library's pub/linux/platform directory. This pub/linux/platform directory is
> a virtual SYSROOT specific to that library.  When installing the library
> into our target root file system, we are able to simply copy the contents of
> the pub/linux/platform directory into the target root file system and all
> works well.
>
>
> When we build an application or another library that depends on the first
> library, this is when things get messy. In order to support this, we have to
> "install" the library into a copy of the target root file system. This is
> undesirable for us. Specifically, we don't want to have to "install"
> libraries into a central root file system in order to build something that
> uses them. It would be ideal to be able to specify multiple SYSROOT
> directories in the PKG_CONFIG_SYSROOT_DIR variable like so:
>
>
>
> PKG_CONFIG_SYSROOT_DIR=$PROGRAMMING/lib_a/pub/linux/platform:$PROGRAMMING/lib_b/pub/linux/platform:$PROGRAMMING/lib_c/pub/linux/platform
>
>
>
> Is such a feature something that you've considered implementing? If not,
> will you consider it? If so, do you know when this feature might be
> supported?

I think you can probably do this with the poorly documented
-uninstalled feature. Then you don't even have to get the libraries
out of their build trees. Suppose you have the real lib_a.pc that
contains directories like your root filesystem. You don't want to
change that since it will break your first case. Instead you can add a
lib_a-uninstalled.pc that contains paths into the build tree (or
staging area) where the built but not installed library will live. If
you extend PKG_CONFIG_PATH to cover the location of all of these
-uninstalled.pc files, then pkg-config will automatically pick those
up.

I'm going to assume for the moment that your build tree is fixed sort
of like above and you build lib_a in $PROGRAMMING/build/lib_a and that
it's a flat directory. So, your build directory for lib_a would have
lib_a.pc, lib_a-uninstalled.pc and lib_a.so all in the toplevel. You
could then construct a lib_a-uninstalled.pc like so:

abs_top_srcdir=$PROGRAMMING/build/lib_a
abs_top_builddir=${abs_top_srcdir}

Cflags: -I${abs_top_srcdir}
Libs: -L${abs_top_builddir} -llib_a

Then you would just build with
PKG_CONFIG_PATH=$PROGRAMMING/build/lib_a:$PKG_CONFIG_PATH and you'd
get the build-tree version picked up. Obviously, if you substitute the
abs_top_srcdir/abs_top_builddir like autoconf, that would make it work
better.

Also, there's one magic variable set intended for -uninstalled.pc.
Inside the pc file you can use ${pc_top_builddir}. Normally,
pkg-config will substitute '$(top_builddir)', which is useful in
automake projects, but you can override it using the environment
variable PKG_CONFIG_TOP_BUILD_DIR. This might not be fine-grained
enough for you since it would apply globally to all the
-uninstalled.pc files, so you'd probably have to resort to building
the -uninstalled.pc files with the build directories hardcoded,
though.

Returning to your idea of multiple SYSROOT_DIRs, I'm not immediately
for it. The idea of the sysroot support was to mimic gcc's sysroot
support, which by design only handles a single sysroot. After all, the
concept of sysroot is that you have a staging root that will
eventually become the real root. That doesn't quite extend to the idea
of multiple staging roots.

--
Dan