Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH zsh-3.1.5-pws-7: cygwin make fixes
- X-seq: zsh-workers 5324
- From: "Matt Armstrong" <mattarmst@xxxxxxxxxxx>
- To: pws@xxxxxxxxxxxxxxxxx, zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: PATCH zsh-3.1.5-pws-7: cygwin make fixes
- Date: Mon, 08 Feb 1999 09:19:02 PST
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
>"Bart Schaefer" wrote:
>> On Feb 7, 10:49pm, Matt Armstrong wrote:
>> } Subject: PATCH zsh-3.1.5-pws-7: cygwin make fixes
>> }
>> } I fixed #2 by re-doing the way signames.c is created.
>> } Instead of a AWK script that gets run on a signal.h file,
>> } a C program is compiled and run. This gets it right even
>> } if the signal.h file is hard to parse.
>>
>> I haven't examined the patch in detail to check this, but did
>> you make sure that the compilation of this program is
>> performed in such a way that it executes correctly on the
>> current hardware even when cross-compiling for >> another
architecture?
>
>The trouble is mksignames actually has to run on the target
>architecture to generate the appropriate signal names. I don't know
>if there's any way of doing that at all with autoconf. Any more
>ideas? We could maybe make it conditional on not cross-compiling,
>since it does solve the #include problem fairly neatly.
Check out my argument to Bart about why I think the mksignames.c
scheme is no less broken than signames.awk in this regard. I think
there is a good chance that cross compiling was already broken, at
least with respect to finding all the signal names.
(And if this is the case, perhaps the code in mksignames.c
should be stuck into zsh itself, wasting a bit of RAM but
getting it right in all cases.)
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Messages sorted by:
Reverse Date,
Date,
Thread,
Author