Summary: | make install fails in XpConfig/ with BuildServersOnly=YES | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xprint | Reporter: | Matthieu Herrb <matthieu.herrb> | ||||||||
Component: | Build config | Assignee: | Roland Mainz <roland.mainz> | ||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||
Severity: | normal | ||||||||||
Priority: | high | CC: | eich, julien.lafon, kem, roland.mainz | ||||||||
Version: | unspecified | ||||||||||
Hardware: | All | ||||||||||
OS: | OpenBSD | ||||||||||
Whiteboard: | |||||||||||
i915 platform: | i915 features: | ||||||||||
Bug Depends on: | |||||||||||
Bug Blocks: | 351 | ||||||||||
Attachments: |
|
Description
Matthieu Herrb
2004-08-27 14:50:24 UTC
Created attachment 751 [details] [review] proposed patch Created attachment 764 [details] [review] Don't run mkfontscale if BuildServersOnly How about just not running mkfontscale when BuildServersOnly is YES? (see patch for details) I've just tested this patch here and it works fine. I'll go ahead and check it in shortly. Matthieu, if this works for you as well, please close the bug. Thanks! Ok, your patch fixes the problem too. I wonder if it makes sense to install these fonts outside of the standard font directory though, but this is left for later. First comment while reading the patch: OUCH. #ifdef'ing out the font/ dirs in the model-config areas isn't the correct solution. These files (which aren't real fonts, the *.pmf files work more like *.afm files (e.g. metrics information)) are part of the model-configs and cannot be removed conditionally - you are simply removing the information about the printer-buildin fonts. Matthieu Herrb wrote:
> I wonder if it makes sense to install these fonts outside of the standard
> font directory though, but this is left for later.
Because this aren't real fonts. These files are font metrics information which
are conditionnally added to the list of fonts when the matching printer model is
selected.
> XpConfig wants to install fonts and run mkfontscale on the font directories.
> mkfontscale is not built in this case.
The correct fix may be simply to build "mkfontscale", use it to generate the
fonts.dir index but don't install "mkfontscale".
Would that work ?
(In reply to comment #7) > The correct fix may be simply to build "mkfontscale", use it to generate the > fonts.dir index but don't install "mkfontscale". > Would that work ? I think that would work as well. Please provide a patch, and I will verify/commit it. The result of make install after a build with BuildServersOnly=YES doesn't work alone. Afaik the main X server still needs the 'fixed' and 'cursor' fonts which are not build nor installed by this build. Requiring that the font metrics are built and installed separatly when doing a build with XServersOnly=YES is not a problem. And about installing those metrics, the current build system puts them in /etc/X11/xserver, which imho is wrong. These data are not supposed to be customized on a per machine basis. So they should better stay in ProjectRoot/lib/X11/. Matthieu, that is an excellent point. Should anyone reasonably expect that an install from BuildServersOnly (with nothing else on the system) to work? The BuildServersOnly test for this release was only a build test -- it was not an install test. The only install tests were (1) no host.def file and (2) a host.def file with ProjectRoot defined and NothingOutsideProjectRoot=YES. I feel that the BuildServersOnly is a facility to speed up the build/test cycle for people doing development. So having make install not installing all required components to run the server is not a problem, since developpers will have these components installed by some other mean. If one sees BuildServersOnly as a step to make a modular distribution, then things may be different and than it may need to install every component required to run the servers, including a minimal set of fonts (and metrics), xkbcomp and its data files... I do not (and I seriously doubt others would) consider BuildServersOnly as a step toward modularization, and for this release, I do not want to hold it up for a solution that would make a BuildServersOnly install fully useable as that would involve a significant amount of work. This was discussed on today's release wranglers call and if any new patches are available by the deadline today at 6pm EDT, then they can be considered. Otherwise, we will go with the workaround that we currently have. Taking bug myself... Created attachment 809 [details] [review] Proposed patch for 2004-09-01-trunk The patch backs out the non-working solution from attachment 764 [details] [review] (well, it wallpapers over the original problem but ruins the model-config metrics data... ;-/) and tries to solve the issue via building mkfontscale (but don't install it) that it can be used later to build the model-config metrics index files (and "fixed" and "cursor" fonts on demand, too). I am not sure whether this can be done better... the |ComplexProgramTarget()| rule doesn't have a flag to "not" install an application so I am simply hacking around that detail via #undef'ing the |Install*| rules. Comment on attachment 809 [details] [review] Proposed patch for 2004-09-01-trunk Requesting r= ... I've looked at this patch and thought about it for a while. I really don't think it is the right way to handle the BuildServersOnly install case. As noted in earlier comments, while the BuildServersOnly install should not fail, the installed code is not expected to work properly unless you are installing over the top of another full build install. The fix suggested uses some internal knowledge of how Imake works to get around installing mkfontscale, which is very kludgy, so I do not think this the correct way to handle it. Also, I don't think it is correct to install the fonts just for the Xprt server when the other X servers (Xorg, Xvfb, etc.) wont work without their fonts installed either. We could install a minimal set of fonts for the other servers to work properly, but I do not think that is good idea. As we are extremely close to the release, I think we should stick with the original solution since that corrected the problem in a very simple way, so I'm going to close this bug. A new bug can be opened against the next release to continue to search for a better solution. Roland: It may be better to turn off the building of the Xp config files completely instead of generating a castrated form which does not work - the current form is broken. |
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.