Bug 5176 - fonts fail to build without mkfontscale and mkfontdir
Summary: fonts fail to build without mkfontscale and mkfontdir
Alias: None
Product: xorg
Classification: Unclassified
Component: Build/Modular (show other bugs)
Version: git
Hardware: All All
: high normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Keywords: patch
Depends on:
Reported: 2005-11-27 09:18 UTC by David Coulthart
Modified: 2008-10-25 13:39 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

cause autoconf to bail if mkfontscale or mkfontdir are not found (592 bytes, patch)
2006-09-13 14:55 UTC, Andres Salomon
no flags Details | Splinter Review

Description David Coulthart 2005-11-27 09:18:01 UTC
When packaging the modular fonts for distribution it is desirable not to run
mkfontscale & mkfontdir during the build, so fonts.scale and fonts.dir can be
generated at install time instead of build time.

If you try to build the fonts w/o mkfontscale & mkfontdir installed, configure
does not die when it can't find them, but just sets the MKFONTSCALE and
MKFONTDIR variables to the empty string.

However, when make install-data-hook runs it tries to execute "$(MKFONTSCALE)
$(DESTDIR)$(fontdir)" and "$(MKFONTDIR) $(DESTDIR)$(fontdir)", but MKFONTSCALE
and MKFONTDIR are empty, so it tries to execute the directory, which results in
make install dying with an error.

I'm not sure what the best solution to this problem is.  A few options I've
thought of are:

* AC_PATH_PROG() could be changed in configure.ac to set value-if-not-found to
something like echo or ls.

* the calls to MKFONTSCALE and MKFONTDIR in Makefile.am could be prefixed by @
so that any errors executing them are ignored.

* the calls to MKFONTSCALE and MKFONTDIR in Makefile.am could be preceded by a
shell construct that checks to make sure the variables aren't empty strings.
Comment 1 Mike A. Harris 2005-11-30 16:04:03 UTC
Different OS distributions may have different standard ways of handling
the fonts.* file creation timing.  In our OS, it is done at font installation
time, since multiple packages could install fonts into the same directory
from the rpm packaging, so one package providing a static fonts.dir generated
at build time is a bad thing.

We work around that easily enough by just forcibly removing any of the
font meta files that might be generated at build time, and then having the
package own them as "ghost" files (files that the package claims ownership
for, but does not provide static files for, instead generating them dynamically
during installation).

So, running mkfont* during build/install is not desireable to us, but we
override it manually and blow the files away anyway.  I'm not sure it would
reduce build/install time much to make it a worthwhile configure option
though to specify not to build the metadata files.

If it is decided to make invocation of mkfont* optional during build, we'd
probably use it tho, but it's not really that big a deal. ;)

Nonetheless, the font packages should probably have a hard requirement on
font-util package if the build/install hard codes executing mkfont*, so this
problem should be fixed.

Comment 2 Jeremy C. Reed 2006-05-25 09:19:42 UTC
This problem hits me too. Installing xserver/xorg fails when running -b command
(because MKFONTSCALE before that is empty).
Comment 3 Andres Salomon 2006-09-13 14:55:22 UTC
Created attachment 6955 [details] [review]
cause autoconf to bail if mkfontscale or mkfontdir are not found

At the very least, the configure script should die if it can't find either one
of these (mkfontscale, mkfontdir).  Otherwise, the build dies w/ strange error
messages because variables are just blank.
Comment 4 Daniel Stone 2007-02-27 01:28:54 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 5 Julien Cristau 2008-10-25 13:39:21 UTC
(In reply to comment #3)
> Created an attachment (id=6955) [details]
> cause autoconf to bail if mkfontscale or mkfontdir are not found
patch applied to (i think) all font modules.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.