Mail Archives: cygwin-developers/1999/03/03/20:56:05
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 AT ibm DOT 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 AT hydraweb DOT 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 AT ibm DOT 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. */
- Raw text -