zsh-workers
 help / color / mirror / code / Atom feed
* Re: PATCH: zsh-3.1.5-pws-7: another go at signames
@ 1999-02-09  7:01 Matt Armstrong
  1999-02-09 11:26 ` PATCH: zsh-3.1.5-pws-7: yet more signames Peter Stephenson
  0 siblings, 1 reply; 3+ messages in thread
From: Matt Armstrong @ 1999-02-09  7:01 UTC (permalink / raw)
  To: zsh-workers

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

* PATCH: zsh-3.1.5-pws-7: yet more signames
  1999-02-09  7:01 PATCH: zsh-3.1.5-pws-7: another go at signames Matt Armstrong
@ 1999-02-09 11:26 ` Peter Stephenson
  0 siblings, 0 replies; 3+ messages in thread
From: Peter Stephenson @ 1999-02-09 11:26 UTC (permalink / raw)
  To: zsh-workers

"Matt Armstrong" wrote:
> 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.

Yuk.  The trouble is, you definitely need the original list of names.
See below.

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

Yes, no argument here.

Plan #3 (which uses plan #2 of yesterday) goes one better by
#include'ing signal.h when configuring, and looking at what cpp
produces to find out what files are actually included.  This list is
then checked for signal definitions.  In principal this can fix
cross-compilation worries, though it requires that $CPP is set to a
preprocessor with the correct include path built into it, and that I
don't know about.  Also, we're at the mercy of output formats for
cpp. I've assumed that it will always look like
#<space or tab><anything>"<name here>"
--- does anyone know of a recalcitrant preprocessor?  Anyway, I left
the old list there as a backup, so we should be no worse off.

One other fix: now that we can rely on the signal number being
replaced only for real signals, I have widened the test in
signames1.awk so that it will match any #define SIG... without a
parenthesis next, and so long as that expands to a number later on we
get the signal.  Again, it's possible some very unfriendly definitions
can mess this about.  It requires, for example, that the `real'
definition comes first.  For example,

#define	SIGABRT    6	/* (*) abort process */
#define SIGIOT  SIGABRT /* abort (terminate) process */ 

still works OK because it gets to SIGABRT first and so doesn't try to
assign SIGIOT to signal 6.  (Arguably zsh should know that SIGIOT
should be a synonym for SIGABRT, but that's a different question.)

Another subtlety I found on SunOS:

#define _SIGRTMIN 38    /* first (highest-priority) realtime signal */
#define SIGRTMIN _sysconf(_SC_SIGRT_MIN)        /* first realtime signal */

Here, to get anything, we need to use the former --- this corresponds
with what's in the native csh.  I've allowed signames1.awk to use
_SIGXXX as if it were SIGXXX.  This used to happen before.  The first
definition encountered will be used.

I have had good results with this on: AIX 3.2, HPUX 10/20, IRIX 6.2,
SunOS 5.6 with the comment above (all, however, with gcc, though I
checked the form of the cc -E output), but it certainly needs testing
as widely as possible.

--- Src/signames1.awk.sn3	Mon Feb  8 18:07:02 1999
+++ Src/signames1.awk	Tue Feb  9 12:18:56 1999
@@ -1,9 +1,19 @@
+# This is an awk script which finds out what the possibilities for
+# the signal names are, and dumps them out so that cpp can turn them
+# into numbers.  Since we don't need to decide here what the
+# real signals are, we can afford to be generous about definitions,
+# in case the definitions are in terms of other definitions.
+# However, we need to avoid definitions with parentheses, which will
+# mess up the syntax.
 BEGIN { printf "#include <signal.h>\n\n" }
 
-/^[\t ]*#[\t ]*define[\t _]*SIG[A-Z][A-Z0-9]*[\t ]*[1-9][0-9]*/ { 
+/^[\t ]*#[\t ]*define[\t _]*SIG[A-Z][A-Z0-9]*[\t ][\t ]*[^(\t ]/ { 
     sigindex = index($0, "SIG")
     sigtail = substr($0, sigindex, 80)
     split(sigtail, tmp)
     signam = substr(tmp[1], 4, 20)
-    printf("XXNAMES XXSIG%s SIG%s\n", signam, signam)
+    if (substr($0, sigindex-1, 1) == "_")
+        printf("XXNAMES XXSIG%s _SIG%s\n", signam, signam)
+    else
+        printf("XXNAMES XXSIG%s SIG%s\n", signam, signam)
 }
--- configure.in.sn3	Mon Feb  8 10:43:29 1999
+++ configure.in	Tue Feb  9 12:03:49 1999
@@ -664,12 +664,27 @@
 
 dnl Where is <signal.h> located?  Needed as input for signals.awk
 AC_CACHE_CHECK(where signal.h is located, zsh_cv_path_signal_h,
-[for SIGNAL_H in /usr/include/bsd/sys/signal.h  dnl Next
-                 /usr/include/asm/signum.h      dnl alpha-Linux
-                 /usr/include/asm/signal.h      dnl Linux 1.3.0 and above
-                 /usr/include/linux/signal.h    dnl Linux up to 1.2.11
-                 /usr/include/sys/signal.h      dnl Almost everybody else
-                 /dev/null;                     dnl Just in case we fall through
+[dnl Look at the output from the preprocessor.
+dnl We should get lines of the form `# 1 "/usr/include/signal.h"'
+dnl The following assumes the real definitions are in a file which
+dnl contains the name `sig'; we could relax this if necessary,
+dnl but then you can get a rather long list of files to test.
+echo "#include <signal.h>" > nametmp.c
+sigfile_list="`$CPP nametmp.c | sed -n -e 's/^#[ 	].*\"\(.*\)\"/\1/p' |
+$AWK '{ if (\$1 ~ \"sig\") files[[\$1]] = \$1 }
+  END { for (var in files) print var }'`"
+rm -f nametmp.c
+if test -z "$sigfile_list"; then
+  dnl In case we don't get the stuff from the preprocesor, use the old
+  dnl list of standard places.
+  sigfile_list="/usr/include/bsd/sys/signal.h
+/usr/include/asm/signum.h
+/usr/include/asm/signal.h
+/usr/include/linux/signal.h
+/usr/include/sys/signal.h
+/dev/null"
+fi
+for SIGNAL_H in $sigfile_list
 do
   test -f $SIGNAL_H && \
   grep '#[ 	]*define[ 	][ 	]*SIG[0-9A-Z]*[ 	]*[0-9][0-9]*' $SIGNAL_H > /dev/null && \

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: PATCH: zsh-3.1.5-pws-7: yet more signames
@ 1999-02-10  6:35 Matt Armstrong
  0 siblings, 0 replies; 3+ messages in thread
From: Matt Armstrong @ 1999-02-10  6:35 UTC (permalink / raw)
  To: zsh-workers

Cool.  Peter, your Plan #3 solves the problem for cygwin nicely, 
provided the following patch is applied afterward.  The patch changes \\ 
to / in the paths that gcc -E likes to spit out.  The \\ seems to 
confuse make.

With this patch, the following abomination shows up in my config.cache.  
It does work, which is what matters:

zsh_cv_path_signal_h=${zsh_cv_path_signal_h='/cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/egcs-2.91.57/../../../../i586-cygwin32/include/sys/signal.h'}


--- configure.in.orig   Tue Feb 09 22:10:30 1999
+++ configure.in        Tue Feb 09 22:24:34 1999
@@ -671,6 +671,7 @@
 dnl but then you can get a rather long list of files to test.
 echo "#include <signal.h>" > nametmp.c
 sigfile_list="`$CPP nametmp.c | sed -n -e 's/^#[       
].*\"\(.*\)\"/\1/p' |
+sed -e 's/\\\\\\\\/\//g' |
 $AWK '{ if (\$1 ~ \"sig\") files[[\$1]] = \$1 }
   END { for (var in files) print var }'`"
 rm -f nametmp.c

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1999-02-10  6:50 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-02-09  7:01 PATCH: zsh-3.1.5-pws-7: another go at signames Matt Armstrong
1999-02-09 11:26 ` PATCH: zsh-3.1.5-pws-7: yet more signames Peter Stephenson
1999-02-10  6:35 Matt Armstrong

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).