Mail Archives: djgpp-workers/2001/02/26/16:12:02
> If you start citing arbitrary sections of the GNU coding standards, I
> can do the same. Node 'System Portability':
>
> As for systems that are not like Unix, such as MSDOS, Windows,
> the Macintosh, VMS, and MVS, supporting them is usually so much
> work that it is better if you don't.
Yes - but that pertains to the decision to support DOS/Windows in the
first place. Also, it refers to the system in the sense of the available
libc functions. For example, DOS has no fork() or pipe(), so programs
that require them would require extensive rewiring to work on DOS.
In this case, the code is obviously portable to DOS (with the patches
sent in by Juan). The only issue here is the filenames used.
> > While it does not require it, this would be especially valid when
> > developing a package that is supposed to work on DOS/Windows.
> Note that dos != windows. I'd even say, dos < windows.
For the purpose of DJGPP, the two are pretty much identical - whether
you're in a Windows DOS box or in plain DOS, DJGPP will allow you to
play with long file names in code - as long as there is a valid 8+3
mapping. The only difference is how the file names appear to the
outside world; on Windows they will retain their LFN look; on plain
DOS, you'd see the (admittedly ugly) truncated names.
> > Admittedly, there are particularly many "problem files" in libiconv, so
> > there would be some work involved
> It is not about the amount of work. It is about the information it
> conveys. "mail-2001-02-26-libiconv-vanHolder" conveys more information
> than "mail0237".
Agreed. But not more than mail/20010226/libiconv/vanHolder.
As I understand it the library will be accessing these files, so there
is no added inconvenience to the user.
And I doubt a programmer will care whether he needs to use
#include <libiconv/iso-8859-1.h>
or
#include <libiconv/iso/8859-1.h>
as long as he gets the definitions he needs.
> You are saying "Cripple your package so it runs optimally on my
> crippled system". I say NO.
No, I'm saying 'Adjust your package's filenames so your package works
cleanly on more systems'. Also, since the headers are involved in the
name conflicts, you're not just making a decision that affects libiconv,
but one that affects all packages using libiconv. Such a package will
now have to use extra configuration changes to include the right headers
depending on the host system.
But in the end, it's your call as maintainer I guess. Just means more
work for the DJGPP maintainers.
- Raw text -