Summary: | "make -f base/unix-gcc.mak" no longer works | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Marcos H. Woehrmann <marcos.woehrmann> |
Component: | Build Process | Assignee: | Hin-Tak Leung <htl10> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P4 | ||
Version: | master | ||
Hardware: | PC | ||
OS: | Linux | ||
Customer: | Word Size: | --- |
Description
Marcos H. Woehrmann
2010-05-14 16:50:08 UTC
(In reply to comment #0) > Because of the FreeType integration the base/unix-gcc.mak and base/unixansi.mak > files no longer work, both produce: > > make: *** No rule to make target `obj/fapif.dev', needed by `obj/fapi.dev'. > Stop. > > > Some of our customers continue to use these files instead of autogen.sh or > ./configure, so dropping support for them will meet with some resistance. I can fix the fapi.dev error (and will commit a change) - but there is another problem further down, which is libtiff - one of libtiff's header file is autoconf generated, so even if you do "make -f base/unix-gcc.mak", you will still need new code to drive libtiff's ./configure. Just ranting - base/unix-gcc.mak is almost the same as base/Makefile.in from which ./configure generates Makefile, so customer who habitually edit base/unix-gcc.mak can edit base/Makefile.in because running ./configure, and it would come to almost the same thing. r11245 adds freetype deps into base/unix-gcc.mak r11246 adds freetype deps into base/unixansi.mak (for general cc) r11247 fixes 8-year old vgs device breakage. (they were not built by default, nor-built in ./configure based-builds, but were enabled during the ESP merge of base/unix-gcc.mak) r11249 generates tif_config.h if it is not there. (top level configure runs tiff/configure to generate this; so it needs extra work in make -f base/unix-gcc.mak build). r11250 - fix 8-year old bitrot in code path which is only used 'make -f unixansi.mak r11248 adds comments about the vga devices being linux-specific. |