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.
(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.