Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Message-Id: <199912090512.XAA16342@mercury.xraylith.wisc.edu>
To: Chris Faylor <cgf AT cygnus DOT com>
cc: Corinna Vinschen <corinna AT vinschen DOT de>,
        cygdev <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: Re: snapshot-991207 
In-Reply-To: Your message of "Wed, 08 Dec 1999 23:22:35 EST."
             <19991208232235 DOT A16604 AT cygnus DOT com> 
Date: Wed, 08 Dec 1999 23:12:50 -0600
From: Mumit Khan <khan AT nanotech DOT wisc DOT edu>

Chris Faylor <cgf AT cygnus DOT com> writes:
> 
> Yes.  It is quote related.  When I was first setting this up I'd tried
> to pass in the build date and cygwin version using the same method that
> you used in your patch but I ran into problems.  I had assumed that
> the usage was something like C where, if you pass in a defined symbol as
> -DFOO="\"This is foo\"" you would be able to use FOO anywhere you can
> use a quoted string.
>
> That doesn't seem to be the case with windres, for some reason.  I kept
> getting syntax errors whereever I used these symbols.  So, I got rid of
> the extra quotes and used STRINGIFY instead.  I was actually surprised
> that this worked...

I'll take a look. The quote handling is unfortunately a mess -- first
the shell (possibly twice, depending on the use exec), and then cpp
called by gcc by windres. However, gcc/cp bit should have the same 
behaviour as with gcc-2.95.2, so I'll double check the shell part.

I believe that the quoting in the snapshot I picked up last night was
wrong, but didn't pay that much attention as to why.

One way to investigate is to run windres by hand and don't provide an
output file, but rather redirect to a file. windres will then just run
the preprocessor and you can look at what cpp gives.

> Thanks, Corinna and Mumit, for actually trying out the new snapshots.
> I assume that since I haven't heard any screams of anguish that the
> new signal code isn't deleting files from your hard disk or something
> similar.

The new signalling code seems to be doing just fine, and it's fixed
one ``randomly hanging'' problem I was having with one of my tools.
However, I notice make hanging indefinitely on Win98 after running
so many jobs, and I have to kill -9 to kill it.

btw, did you get a chance to look at enabling-signals-for-dynload patch?

> -winver.o version.cc: mkvers.sh include/cygwin/version.h winver.rc $(DLL_OFIL
> ES)
> +version.cc winver.o: winver_version
> +	@/bin/true
> +
> +winver_version: mkvers.sh include/cygwin/version.h winver.rc $(DLL_OFILES)
>  	@echo "Making version.cc";rm -f $@;\
					^^^
					version.cc
>  	$(SHELL) ${word 1,$^} ${word 2,$^} ${word 3,$^} $(WINDRES) > $@
                                                                    ^^^^
								  version.cc
Few typos there. Also, it has a few other problems -- eg., run make, 
delete winver.o and re-run make. As it is now, winver_version is also
not a "phony".

Unfortunately, I can't check till tomorrow afternoon or so.

Regards,
Mumit