[bug-gs] 8.12: minor issues: non-doc

[Ralph Giles]

On Mon, Dec 22, 2003 at 06:16:02PM -0500, der Mouse wrote:

>     I don't understand how t_eps managed to come out negative.  Either
>     clock()'s return value decreased or the second call failed, it
>     appears, and neither of those looks very possible - but it quite
>     definitely happened.

Interesting. Have you looked at <http://bugs.ghostscript.com/show_bug.cgi?id=687184> ? Sounds like 
it might be related. I don't understand what's going on in either case, but it's something new. 
Was this also on a P4?

> Why does unix-gcc.mak include "libdir = $(exec_prefix)/lib" when
> unixansi.mak doesn't?

Probably because libdir is only used for the shared library build (as an install location) and the 
library build is not supported on generic unix. Note also that both of these makefiles are 
deprecated in favor of the autoconf build (src/Makefile.in and src/configure.ac).

>     Adding $(PSD)/rasterop.dev to FEATURE_DEVS doesn't seem to work.

You want $(PSD)rasterop.dev here. The directory makefile variables ending in 'D' include the 
trailing virgule. Because of the way FEATURE_DEVS gets turned into a list of targets, the 
double virgule doesn't get collapsed the way it would in a file reference.

>     NetBSD's make(1) has a delightful little bug (well, I call it a
>     bug, though since it's clearly deliberate I suppose it really ought
>     to be called a misfeature) whereby, in the absence of being
>     specifically told not to (by environment variables), if a
>     subdirectory obj/ exists, it will at startup chdir into it.  This
>     of course breaks commands that (not unreasonably) expect the
>     current directory to be the starting directory.  While this isn't
>     an issue for a successful build, it causes trouble if anything
>     breaks and you try to restart the build without destroying obj/
>     first (just emptying it out isn't enough).  While I hesitate to
>     suggest renaming obj/ just to work around something that shouldn't
>     have been put there in the first place, maybe an OS-specific
>     section for NetBSD should be added that warns of this?

Bizarre. Is there a switch to turn off this behavior?

Thanks for all the reports, we definitly appreciate your input and it's nice to have a fresh look 
at the process we've all grown used to.

 -r