Mail Archives: djgpp/1998/10/29/21:58:01
Mike Ruskai wrote:
> No, in fact it does not require an extra installation step. It is already
> the case that someone using long filenames will have to take an extra step to
> configure the compiler for that circumstance. I am merely stating that said
> extra step should also remove from the archiver the role of ensuring the
> correct filenames for compiler components.
See below.
> Unzipping the package in a fashion that breaks its functionality does not
> result in such an obvious malfunction as you seem to imply. In fact, the
> problem is quite subtle indeed, only showing up when certain includes are
> required (such as streambuf.h, itself included from iostream.h).
On reflection, you're right.
> Packaging the program as I've suggested would provide complete functionality
> for normal use. Someone who for some reason includes streambuf.h directly
> would surely realize that long filenames are required, and take the step
> necessary to enable them (ideally, simply running a supplied program).
A moderately naive Windows user would have no reason to expect that they
would not be enabled, and simply become confused when it didn't work.
RTFM'ing might help, but then, if people would RTFM, we'd be out of a
job :)
> This happens to be the exact method employed by the EMX development package,
> which is an OS/2 port of GCC. While DJGPP is hampered by the fact that there
> is no script language in DOS or Win95, it is a fairly trivial matter to write
> a simple program to perform the task. A program which, properly written,
> could be easily modified to reflect the current package contents; ideally
> written, it would operate entirely based on a configuration file.
>
> >I don't see why you should need to change the headers at all, actually;
> >#include <streambuf.h> will work equally well on vanilla 8+3 and
> >Windows/LFN=Y. OTOH, people who leave LFN=N would have to set it =Y
> >when they run the script, or else they lose, so it might not gain all
> >that much.
>
> What possessed you to make such a claim. This very thread was begun because
> of the fact that '#include <streambuf.h>' does not in fact work equally well
> with or without long filenames.
>
> Perhaps it is best demonstrated thusly:
>
> 1-s
> 2-t
> 3-r
> 4-e
> 5-a
> 6-m
> 7-b
> 8-u
> 9-f
It works on a completely non-LFN system (MS-DOS < 7): when opening
"streambuf.h", the extra character is dropped and you get "streambu.h".
Since the same thing happened when unzipping, it's found. Try it and
see.
On an LFN system where LFNs are enabled, it also works, provided the
long name was used in creating the file. I think we've established
that.
The cases that don't work are:
1. LFN platform/LFN's disabled in DJGPP/File created with Winzip or
similar/NameNumericTail=1
2. LFN platform/LFN's enabled in DJGPP/File created with PKUNZIP
1 will go away when LFN=Y is the default, and 2 seems empirically to be
very uncommon. Most newbies use Winzip.
> >I suppose the other tricky bit is that the people creating the package
> >have to generate the script. But it could presumably be somehow
> >automated.
>
> I very much doubt that someone who can write a compiler is incapable of
> writing a program to correct include files. I can't do the former, but can
> easily do the latter.
The person packaging the compiler for DJGPP is not necessarily the
person who wrote said compiler. But I agree it's not a horrendously
difficult task.
OTOH, I believe Eli's point is well made that much of this complexity
will soon be unneeded, when LFN=Y. People who want or need to use
Windows without LFNs can find, with minimal RTFM'ing, that PKUNZIP will
solve their problems. Same goes for OS/2 and so on.
--
Nate Eldredge
nate AT cartsys DOT com
- Raw text -