Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
X-Apparently-From: <tailbert AT yahoo DOT com>
From: "edward" <tailbert AT yahoo DOT com>
To: "DJ Delorie" <dj AT delorie DOT com>
Cc: "Cygwin Developers List" <cygwin-developers AT sources DOT redhat DOT com>
Subject: RE: doctool.c patch
Date: Thu, 7 Dec 2000 13:31:53 -0500
Message-ID: <FMEOJCMLNIMPBKAPFPIHKEFKCFAA.tailbert@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200012071740.MAA05051@envy.delorie.com>
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal

DJ,

The code as is doesn't work on the link farms generated by an
all-target-winsup.

The test for using stat vs. lstat is done at compile time due to the test

#ifdef S_ISLNK
#define STAT lstat
#else
#define STAT stat
#endif

Since cygwin has S_ISLNK defined, lstat is used. This works fine for regular
files, but files which are actual symlinks don't pass the
S_ISREG(st.st_mode) test. This appears in the all-target-winsup scenario
above.

The all-target-foo setup generates real directories, but symlinks everything
else. The code as is works fine in the winsup/doc directory, but not in a
full binutils chain. By adding the S_ISLNK test, we can get both situations
to work.

But when I think about it, it's a bit cleaner to follow your suggestion of
changing the lstat to a stat, and use S_ISREG. It's one less comparison and
accomplishes the same thing.

In any case, I understand the reasoning behind the disallowing symlinks,
when you recursively descend a source tree. However, I would argue that
keeping the paradigm of the all-target-foo is probably worth doing. Both
winsup and newlib does that, as well as a number of the gcc subdirectories.
At the moment, the doctool breaks in a unified source tree.

Since I like having the source unified because it allows me to test the
winsup stuff in conjunction with a dozen or so apps, I find it useful.

So, what do you suggest?

-----Original Message-----
From: cygwin-developers-owner AT sources DOT redhat DOT com
[mailto:cygwin-developers-owner AT sources DOT redhat DOT com]On Behalf Of DJ
Delorie
Sent: Thursday, December 07, 2000 12:40 PM
To: tailbert AT yahoo DOT com
Cc: cygwin-developers AT sources DOT redhat DOT com
Subject: Re: doctool.c patch



> Enclosed is a patch for winsup/doc/doctool.c. I've extended it to allow
> symbolically linked files to be considered as valid source files. This
> allows doctool to find the correct files for those of us who check out the
> entire :/cvs/src tree and use the configure-target-winsup to compile
winsup.

doctool specifically uses lstat to avoid symlinks.  Your patch undoes
that.  If this is really what you want, then you have to consider two
things:

1. The original code is there to avoid symlinks.  Why?  What problems
   could symlinks cause, that the original author already encountered
   and dealt with? (hint: symlinks to directories, symlinks causing
   duplication)

2. If you want symlinks treated as files, just take out the lstat/stat
   logic, and always use stat.

Plus, you dind't include a ChangeLog entry.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com