Re: Question about making changes...

[fortinj@ibm.net]

Chris Faylor wrote:
> 
> The development sources are always "moving right along" and often we discuss
> the changes we're making in the cygwin-developers mailing list.
> 
> You can easily find out what has changed by inspecting the ChangeLog entries.
> That's one of the reasons DJ made the ChangeLog entries available.
> 
> I do appreciate the fact that you decided to pitch in and help but I am
> somewhat mystified as to why you would expect sources that are 1.5
> months old to be the correct place to start.  We provide the snapshots
> to developers so that they can get the latest versions.  I realize that
> it's not easy to keep up with a moving target but you should still look
> for the latest and greatest if you are about to undertake making
> changes.
> 
Well, that was part of the question...  I know that the snapshots are 
	1) not always compilable to the DLL
	2) and reading the changelog, I did see that there were several
function deleted and re-added and then deleted again in path.cc.

	You have to start somwhere, and the stable sources from 1/15 seemed
logical at the time.  I did download the snapshot from 2/22
(cygwin-src-19990222.tar.gz) and it did not compile.  So somewhere btwn
1/15 and 2/22 somthing broke.  It may have been a problem here.  At that
time I wasn't able to dig into it further.

	So it not really a complaint, but what to do....

	Even after all this I still have a much better feel for the code than I
did before.  I even downloaded the eval of Source-Navigator in order to
see if it would help.  It did. 


> cgf
> 
> On Wed, Mar 03, 1999 at 08:19:00PM -0800, fortinj@ibm.net wrote:
> >       The following is an e-mail posted to the regular list.  I was curious
> >and decided to examine this.
> >
> >Alexander Dupuy wrote:
> >>
> >> CygWin applications converting a relative pathname with drive letter A:FOO
> >> (but not A:\FOO, as that specifies an absolute path on A:) will get //AFOO
> >> as the POSIX pathname, which is incorrect.  ("cygpath -u A:FOO" to confirm
> >> this). The correct conversion should take into account $!A, and provide an
> >> absolute pathname (since POSIX pathnames can't support a relative pathname
> >> to a file on another drive.  I'd provide a fix for this myself, but I just
> >> started with CYGWIN, and haven't loaded sources yet.
> >>
> >> @alex
> >> --
> >> mailto:dupuy@hydraweb.com
> >>
> >
> >       I had (have) the jan 15 snapshot installed.  I figured that this was a
> >decent way to start understanding the underpinnings of cygwin.
> >
> >       I was pretty happy.  I fixed what looked like a bug in path.cc
> >( see diff that follows) and was going to send it in to be looked at.
> >However, I looked at the newest snapshots and saw that path.cc had been
> >pretty much rewritten.  My fixes were not appropriate for the rewrite.
> >
> >       My question is this.... Without downloading, and 'hopefully'
> >recompiling every snapshot, how do I know when, and where to start
> >debugging.  The time I spent was not a waste of time because I did get
> >to examine, and debug in cygwin1.dll  but it was frustrating when I
> >discovered my changes were not usable.  And there seems to be a HUGE
> >difference btwn the B20.1 release and the current snapshots.  This is a
> >good thing I believe, but does cause complications in keeping code and
> >DLLs in sync.
> >
> >       Any and all comments will be appreciated, and thanks...
> >
> >John Fortin
> >fortinj@ibm.net
> >
> >
> >*** path.cc    Wed Mar 03 01:02:40 1999
> >--- path.cc.old        Wed Mar 03 01:03:36 1999
> >*************** build_slash_drive_prefix (const char *pa
> >*** 2070,2077 ****
> >    buf[0] = '/';
> >    buf[1] = '/';
> >    buf[2] = path[0];
> >!   buf[3] = '/';
> >!   return buf + 4;
> >  }
> >
> >  /* Convert PATH (for which slash_drive_prefix_p returns 1) to WIN32
> >form.  */
> >--- 2070,2076 ----
> >    buf[0] = '/';
> >    buf[1] = '/';
> >    buf[2] = path[0];
> >!   return buf + 3;
> >  }
> >
> >  /* Convert PATH (for which slash_drive_prefix_p returns 1) to WIN32
> >form.  */