Re: PATCH: zsh-3.1.5-pws-7: another go at signames

["Matt Armstrong" <mattarmst@hotmail.com>]

Peter Stephenson <pws@ibmth.df.unipi.it> writes:

> There was another, more drastic problem with what Matt had: it
> required you to know all the possible signals, since you never got
> to see the names if you didn't know them already.  That's pretty
> hairy, given the stuff that gets shoved into OSes --- it would have
> needed major additions just for AIX here.

Yes.  I considered this as part of porting zsh to a platform.


> This is pretty much Bart's idea above.  (It still needs the right
> signal.h, but so does every other idea.)

Not my original scheme.  It always gets the right one because it
relies on the compiler to find it, not configure.

The signal.h on a cygwin system can be pretty much anywhere.  On my
machine it is at
/cygnus/cygwin-b20/H-i586-cygwin32/i586-cygwin32/include/sys/signal.h.

Also, if the point is to support cross compiling, I don't think the
fixed list of header locations in configure.in will cut it.  It will
likely pick up the signal.h for the host system, not the target
(though, I have to admit I've never cross compiled from one unix to
another -- maybe the same set of headers is typically used?).

It took me a while to figure out that zsh's "kill -l" listed only ZERR
because configure wasn't finding my signal.h.  (maybe I should
consider this part of porting zsh to a new platform!  :-)


> I managed to get an identical signames.c to the one before.  Matt,
> does this fix your problems?

Fortunately, cygwin lets me mount the path mentioned above to
/usr/include.  This lets configure find the right signal.h.

And, what really counts, it creates a correct signames.c!

If we stick with the improved AWK based scheme, I'll add a Cygwin
section to Etc/MACHINES describing how people should create their
/usr/include and that they should do it before running configure.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com