Mail Archives: djgpp-workers/2000/01/20/02:26:28
On Wed, 19 Jan 2000, Michel de Ruiter wrote:
> - Most important one (IMHO): src/stub/djasm.y generates time-stamps
> like "$Id: stub.asm built 18/01/100 14:20:56 by djasm $" which also
Yep, thanks for the patch.
> - Many of the zip files contain CVS directories, although I think they
> are of no use.
Which ones? I don't see even a single CVS directory in my copies of
the zips.
> - djtzn203.zip (IIRC) has a problem when unzipped without LFNs; it
> contains both zoneinfo/australia/CVS and zoneinfo/australasia/CVS.
Unless I miss something, `australia' gets truncated to `australi',
while `australasia' gets truncated to `australa'.
One of the alpha versions had a problem whereby there were both
`australia' and `Australia' (with a Capital A), but I corrected this
before the release.
> - Now that we use the nroff-code for info/time2posix.3, maybe we
> should copy info/time2posix.3 to info/posix2time.3 too?
They are simply the source and the formatted output of the same page.
I kept the old name for compatibility (though I'd be surprised if
someone besides me ever read those pages ;-).
> - I see src/debug/common/symify.c lacks Eli's new code that does
> dynamic memory allocation and abbreviation, etc.
I do see the code I added. What date is on symify.c in your copy of
djlsr203? Mine is 24-Dec-1999.
> - What is the file src/typescript? Another unwanted leftover:
> zoneinfo/src/core
I don't see those. They were in some old zip file during alpha, I
think, but I removed them before the release.
Is it possible that you downloaded some old alpha version from the
alphas subdirectory on SimTel.NET? What size and time stamp are your
dj*203.zip files?
> - src/gcc*.opt: why do we still use the -fno-strength-reduce and -m*
> options?
Because the library was produced by GCC 2.8.1. We didn't yet switch
to GCC 2.9x for building djdev.
> - Why are the following still in djgpp.env, can't they do any harm?
> +TEXMFMAIN=%DJDIR%/share/texmf
> [cpp]
> CPLUS_INCLUDE_PATH=%/>;CPLUS_INCLUDE_PATH%%DJDIR%/lang/cxx;%DJDIR%/include
> C_INCLUDE_PATH=%/>;C_INCLUDE_PATH%%DJDIR%/include
> OBJCPLUS_INCLUDE_PATH=%/>;OBJCPLUS_INCLUDE_PATH%%DJDIR%/include;%DJDIR%/lang
> /objc
> OBJC_INCLUDE_PATH=%/>;OBJC_INCLUDE_PATH%%DJDIR%/include;%DJDIR%/lang/objc
> [gcc]
> LIBRARY_PATH=%/>;LIBRARY_PATH%%DJDIR%/lib
I don't see anything wrong with these. They are there mainly for
back-compatibility, but they shouldn't do anything bad with latest
versions of GCC and Kpathsea/Web2c. If you think they can do any
harm, please explain why.
> - In readme.1st:
> ...
> program. However, the Berkeley license has been changhed in July
> ... ===
A typo. Thanks.
> - Some makefiles contain a tab on a line of its own.
I don't like changing files just to alter whitespace. These TABs
don't do any harm. Emacs shows them in special color because they can
be dangerous in some cases, but not in our makefiles. In particular,
it is *never* dangerous if there's no preceding rule line.
> - There is one more place where c:/djgpp is hardcoded:
Thanks for catching this.
- Raw text -