[Buildroot] [PATCH-FOR-NEXT v1 3/6] pkgconf: add host-pkg-config wrapper
Thomas Petazzoni
thomas.petazzoni at bootlin.com
Thu Feb 22 09:41:46 UTC 2018
Hello,
Thanks for the feedback!
On Thu, 22 Feb 2018 10:27:13 +0100, Arnout Vandecappelle wrote:
> > I've been thinking about this for a while, and I remember having a
> > discussion about this with some other Buildroot developer a while ago.
> > I think the most correct thing to do would be:
> >
> > $(HOST_DIR)/bin/pkg-config returns results valid for native compilation
> >
> > $(HOST_DIR)/bin/<tuple>-pkg-config returns results valid for cross-compilation
>
> This sounds like a good idea, but as you note below, could lead to breakage as
> well.
Yes.
>
> An alternative would be (IIRC this idea was launched by ThomasDS (added in Cc)):
>
> $(HOST_DIR)/bin/ contains binaries valid for native compilation (i.e. no
> cross-compiler, cross-pkg-config, ...)
>
> $(HOST_DIR)/<tuple>/bin contains binaries valid for cross-compilation
Changing this will also lead to a lot of breakage. All our users who
have scripts doing $(HOST_DIR)/bin/<tuple>-gcc will be broken. I would
even qualify it as an even more radical change, breaking even more
stuff.
And more importantly, the result is not great. I think the most correct
result is to have a single HOST_DIR/bin, with both native and cross
compilation tools, with cross-compilation tools prefixed by <tuple>.
> > I.e, the current pkg-config wrapper should be renamed
> > <tuple>-pkg-config, and pkg-config should behave like a normal native
> > pkg-config, except that it provides results for libraries located in
> > $(HOST_DIR).
> >
> > The autoconf PKG_CHECK_MODULES() macro uses PKG_PROG_PKG_CONFIG(),
> > which internally uses AC_PATH_TOOL(). And AC_PATH_TOOL() will first
> > search for the program with the host machine tuple, and warn if the
> > program cannot be found with this tuple. From
> > https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Generic-Programs.html:
> >
> > """
> > When cross-compiling, this macro will issue a warning if no program
> > prefixed with the host type could be found. For more information, see
> > Specifying Target Triplets.
>
> Weird, I checked a couple of log files and I could see no such warning. Ah,
> that's because we pass PKG_CONFIG=... in the environment.
Yes, I believe it is because we pass PKG_CONFIG=.
> Is it the idea to remove that from the environment then?
Not necessarily, because PKG_CONFIG may be used by non-autoconf based
packages. Some non-autotools packages do:
FOO=`$PKG_CONFIG ...`
> Anyway, the PATH-based alternative will not remove this warning, but that
> shouldn't be different from the current situation.
>
> > """
> >
> > I know this change will:
> >
> > - Potentially break a number of packages we have in Buildroot, which
> > directly use pkg-config without first trying to use
> > <tuple>-pkg-config
>
> I.e. anything not using autotools? Well, most will probably heed the
> PKG_CONFIG=... in the environment.
Most yes, but not all. Some of them do:
FOO=`pkg-config ...`
which currently works because PATH contains $(HOST_DIR)/bin, and
pkg-config returns correct results thanks to us injecting the proper
PKG_CONFIG_LIBDIR and PKG_CONFIG_SYSROOT_DIR depending on whether we're
building a host or target package.
> The PATH-based alternative doesn't have this potential breakage.
>
>
> > - Potentially break a number of downstream users who are using
> > pkg-config.
>
> The PATH-based alternative reduces this problem, downstream users just have to
> add $(HOST_DIR)/tuple/bin to their path (and Buildroot will do this for post-xxx
> scripts).
Well, they still have to change to $(HOST_DIR)/tuple/bin, which means
it breaks stuff for them anyway.
> > However:
> >
> > - It would solve that once you add $(HOST_DIR)/bin to your PATH, you
> > cannot anymore do native builds because "pkg-config" returns results
> > that are not relevant for native builds. I already saw a number of
> > people affected by this.
>
> The PATH-based alternative solves this as well.
>
> Note BTW that neither alternative solves the problem when building a host-tool
> during a target build (and yes, we have seen this problem already in some
> packages). AFAICS, autotools will also for host builds use the PKG_CONFIG passed
> in the environment or discovered through the tuple. Same for CMake.
Potentially autotools could be taught about PKG_CONFIG_FOR_BUILD, just
like it does for CC_FOR_BUILD and al. But that's obviously not
supported by packages today.
> > - It would comply with the standard autoconf expectations.
>
> With the PATH-based alternative, it might make sense to have the cross-stuff
> both in $(HOST_DIR)/bin with the tuple prefix, and in $(HOST_DIR)/tuple/bin
> without the prefix. That way, we get the advantages of both: comply with
> autoconf expectations, and avoid breaking packages or downstream users.
I'm still not convinced about changing the HOST_DIR/ organization. It's
a massive change, affecting everything, and not just pkg-config, and
the outcome is less nice than what we have today, for my perspective.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
More information about the buildroot
mailing list