[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