[Gs-devel] gs 7.03 makefiles are broken, again

[Igor V. Melichev]

Peter,

> From: gs-devel-admin at ghostscript.com on behalf of L. Peter Deutsch
> [ghost at aladdin.com]
> Sent: 24 юъ? сЁ  2001 у. 09:39
> To: gs-devel at ghostscript.com
> Subject: [Gs-devel] gs 7.03 makefiles are broken, again

> 3) OP and INT_MAK are undefined in lib.mak.

I've fixed this.

> 4) UFST_ROOT and UFST_BRIDGE are undefined in lib.mak; UFST_BRIDGE,
>    UFST_ROOT, and UFST_LIB_EXT are undefined in int.mak.  These occur
>    because whoever added the UFST machinery decided it wasn't important to
>    avoid cluttering the build output with warnings, and also decided that
>    (unlike all other configurable options) it was not necessary to put
dummy
>    definitions for these options in the top-level makefiles.

UFST machinery was added by me.

Raph and me had discussed this issue, and decided that undefined
variables are not harmful. They assumed to have empty value.
The logics of conditional integration of UFST is based on this fact.

I have no possibility to test makefiles for all platforms.
Therefore we supposed that possible fixes will come from
other users later.

Actually I was against the integrating of UFST into GS makefiles.
I still believe that UFST plugin to be build independently on
Ghostscript, and the a client installs the plugin to Ghostscript.
Raph forced me to redesign as you see now. Besides others, I'm still not
sure
how GPL can be applied to Gnu Ghostscript with UFST,
because UFST isn't a free software, and my UFST plugin doesn't
form an independent "Program" - see Gnu FAQ.

> #3 is a symptom of an architectural misunderstanding that is absolutely
> guaranteed to cause rot in the immediate future: for example, it
guarantees
> that the PCL interpreter and the graphics library test program will not be
> compilable in an environment that includes only the GS graphics library
and
> not the PostScript interpreter.

Actually the change to lib.mak (with the fix I mentioned above) was done
especially for compatibility with PCL. The module gxfapi.c is a
common part for GS and PCL about UFST.

> There are two things about this set of problems that I find particularly
> annoying:
>
> - They are all mechanically detectable by make --warn-undefined-variables.

This option cannot recognize with Microsoft's nmake, which is my main
development tool.

> - They did not happen when Aladdin was responsible for the release
process:
>   they are new in the past year, and they seem to recur in every release.

I am not sure, what you are about. I committed changes into CVS HEAD *after*
I received notice from Raph about branching CVS. Therefore I was
sure that this change goes to development branch, and did not go to
the recent release. Is this wrong ?

Also I'm not sure, what is wrong if the development branch sometimes
appears buggy. The development branch is only storage before portability
testing,
and only this storage is common for all developers. An alternative is a
single developer
which tests all platforms. I believe that we are unable to go back to
such technology due to the growth of GS code. Another alternative is to
close
the development branch from public access, moving it to a private server.

> A) As part of the regression test, run tmake (not make) with

First I need to make the regression test staff to run on Windows.
Currently its code is too far from Windows due to different structure of
file paths.
Then, I need to know, what is tmake, and how to run it on Windows.
Also we'll need it for Mac.

> B) In order to provide a partial mechanical check against the constant
>    attempts (mostly inadvertent) to break Ghostscript's architectural
>    layering, require that the nightly regression test build and run the
>    gslib test program successfully in an environment that contains ONLY
the
>    graphics library files -- no code whatever from the PS interpreter,
>    including .h files, .mak files, etc.

I believe that 'make' to be involved 3 times from a batch file :
first to build the graphics library as object library, then for
building GS with the object library, then for building PCL with the object
library.
This is only a way for full testing of independent builds,
because --warn* tricks appear not portable.

> I just did (A), and tmake found not only all of the undefined macros but
> also the fact that UFST_INC and UFST_INC1 are redefined with different
> values at different places (once in lib.mak, once in int.mak).  This
> indicates yet further design problems with the UFST part of the makefiles.

I need to understand better, what's wrong here. I assumed UFST_INC and
UFST_INC1
to be a temporary *variables*. Does this contradicts the logics of 'make',
to some coding style, or else ?

> I will beef up tmake to produce warning messages as detailed as those
> produced by make regarding undefined or redefined macros.  Meanwhile, does
> anyone else have suggestions about how to keep these problems from
> recurring?

My old suggestion is to remove UFST plugin from Ghostscript.
Build it independently and then install to GS with a new special
GS API function. Note it is only for few authorized customers.

Igor.