[MPlayer-dev-eng] [PATCH] directfb -> pkg-config
Rich Felker
dalias at aerifal.cx
Tue Feb 21 00:27:13 CET 2006
On Mon, Feb 20, 2006 at 08:55:02PM +0100, Enrico Weigelt wrote:
> * Ivan Kalvachev <ikalvachev at gmail.com> schrieb:
>
> <snip>
>
> > The only problem if we try to detect library when pkg-config fails
> > is that the configure would be a little bit bigger and slower.
> > I don't see this as problem as long as there are cases where
> > pkg-config could fail and detection would work.
>
> In other words, you suggest an multi-step detection. This is okay,
> if it can be easily disabled, ie. "--disable-autodetects" or maybe
> "--pkg-config-only" prevents running the builtin tests and only
> relying on pkg-config. This is sometimes necessary (ie. in sysroot
> environments) to prevent false-positives.
>
> For example, imagine we check for directfb by looking for
> /usr/include/directfb.h. The host system has directfb installed,
> but the (sysroot'ed) build environment has not. You can easily
> see, that we get an false positive, which ends up in an broken
> build. (the compiler won't find direcfb.h, since its outside
> of its sysroot).
I'm not sure how sysroot works or what it is, but IMO it's incorrrect
to read any headers from /usr/include if you're building in a
sandbox/isolated/crosscompiling environment.
> IMHO the best solution is to simply write an own pkg-config
> style script, which handles the packages required by mplayer
> and is called if $PKG_CONFIG is not set.
....
This is a very bad solution, since it would need to duplicate a lot of
code from configure and would not have as much flexibility in setting
variables in the main configure script. It also imposes a bad design
(pkg-config) on a fairly decent design (mplayer's configure script).
Rich
More information about the MPlayer-dev-eng
mailing list