Bug 5176

Summary:

fonts fail to build without mkfontscale and mkfontdir

Product:

xorg

Reporter:

David Coulthart <david.coulthart>

Component:

Build/Modular

Assignee:

Xorg Project Team <xorg-team>

Status:

RESOLVED FIXED

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

high

CC:

dilinger

Version:

git

Keywords:

patch

Hardware:

All

OS:

All

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
cause autoconf to bail if mkfontscale or mkfontdir are not found	none

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.