Re: EMX on DOS

[Paul Edwards]

"Derek Robert Price" <derek@ximbiot.com> wrote in message 
news:mailman.3010.1067872518.21628.bug-cvs@gnu.org...
> Of course, HAVE_LONG_FILE_NAMES is only being used in one location in
> lock.c.  It might not be terrible if HAVE_LONG_FILE_NAMES (which we are
> fairly certain will not be set in a DOS environment) was used to
> restrict CVS's files to 8+3 filenames since 8+3 filenames probably work
> on whatever system it is that restricts file names to 14 characters.
>
> You should read the sections of the Autoconf manual on DOS portability.
> One of them mentions a doschk package which can be used to "easily
> detect" some DOS limitations.

It is CVS limitations that are causing a coredump, not DOS.
I've already submitted a fix.

> |>ahead with a DOS port, you might want to look into DJGPP
> |><http://www.delorie.com/djgpp>.  DJGPP is a 32-bit DOS portability
> |>layer.  Much like Cygwin, I think, except I think more care was taken to
> |>actually provide for DOS quirks like 8.3 filenames.  I've seen the
> |>patches come across the Autoconf list for this.  Anyhow, if you hadn't
> |>guessed, DJGPP comes with a Bash port to run configure scripts.
> |
> |
> |EMX is a 32-bit DOS portability layer too. I already have
> |this installed and already working.  What I don't have is a
>
>
> What makes EMX preferrable to, say, the GPLed DJGPP or Cygwin?

I didn't say it was preferrable, I said it is an example system,
it happens to be the one I use, and CVS, because it isn't
portable, won't run on it.

Even after EMX has gone to so much trouble to add much
of the Unix baggage which is not native to DOS.  Not native
to MVS either.

You may as well tell me to switch to using Unix.  That
installs and runs on my system too.  Might trash my hard
disk in the process, but nevermind, at least it frees up a
lot of disk space.

People who write portable code don't tell the end user to
install a different compiler, when there's nothing wrong
with the compiler, there's something wrong with the
source code.

> |working shell program.  Posix compliant should not be dependent
> |on having non-Posix extensions that aren't even remotely C.  C
> |is what is portable.  Shell is not.  Not all posix systems have
>
> Your platform _can_ run shell.

NO it can't.  That's like saying that the Macintosh can run
Amiga programs.  Sure, they may have such an emulator.
The native Win 98 shell does NOT run shell scripts.  But
it does have multiple C89 compilers available.  MANY
of them.  And even some Posix compliant ones.

> I don't see why you expect the CVS
> development team to deal with your Cygwin installation problems.  It

I expect to be treated as part of the development team to
port CVS to an arbitary and unspecified Posix platform.
As it should have been, out of the box, right from the start.

A "hello, world" program requires nothing more than a
C89 compiler.

A posix 1003.1 compliant program requires nothing more
than a posix 1003.1 compiler and libraries.

If you can't write properly portable code, that works on C89,
at least try to meet the Posix standard.

> seems to me that would be a more relevant on a Cygwin list.  In

Cygwin works fine, thanks for asking.  No compile errors
on any Posix code I have fed it to date.

> addition, you might be able to use DJGPP.  I really don't want to spend
> very much time resolving problems that have already been solved.  I have
> enough to do.

I've solved it already.  With the patches I sent in, CVS is
now Posix compliant.

> |all the dependencies in configure, but they do have all the things
> |required by the Posix 1003.1 standard, ergo why they are posix
> |compliant.  My installed and working EMX system only came
> |with the compiler.

> I'm usually inclined to think of the emx & os2 directories as nusiances,
> as as near as I can tell they are usually not in a working order and
> receive little support.  Even the windows-NT directory's code remains
> broken much of the time due to a lack of developers on the platform and
> the lack of test scripts to run there.
>
> Thus, adding another nusiance directory, POSIX or not, to slowly suffer
> from bitrot due to lack of support is not particularly appealing to me.
> I might reconsider if it meant that we could eliminate one or more of
> the other nusiance directories.

Ah!  An excellent point.  This is EXACTLY what I see the
cvs 1.11.x branch doing.  Given that there's only bug fixes
going in, it means that the next time the windows-NT directory
is updated, it will probably be the last time it ever needs to
be updated.  No-one's going to add code to break it anymore.

The same as that other legacy system that someone was
going to add a fix to, and there was no encouragement for
him to do it.  I would have LOVED to see CVS running on
the Tandem again, like it used to.  And OS/2 etc etc.

I sincerely believe that CVS 1.11.x could become a package
with 0 entries in BUGS, and working on every platform
anyone wishes to submit a patch to fix.

Or could we set up another branch that will have that as
its design goal?  And include that bug fix for symbolic
links too.

> |BTW, without changes to CVS source code, it is not possible
> |to be able to use the "\" that is used in DOS.
>
> It can't be used in arguments.  It does sometimes come out in the error
> messages, which makes it annoyingly complicated to run the sanity.sh
> test scripts.

In the CVS 1.11.9 windows executable that you were kind
enough to provide to me, I can indeed use native Windows
filenames, e.g. in my CVSROOT.  Just as the gods intended.

> Configure detects PATH_SEPARATOR automatically, and this could then be
> defined in config.h if you want to give a shot at fixing that.

Configure detects nothing useful on my system, and even if
it did, the code is wrong and needs to be changed for Windows.

E.g. my CVSROOT is set to o:\cvs

The windows port does exactly what I expect a portable
CVS to do on my system.

> |>There is a
> |>separate version in the windows-NT directory, for example.  If the
> |>version in src doesn't have a switch for platforms which don't allow
> |>renames over existing files, I would guess the issue hasn't been raised
> |>previously or nobody noticed if it was.
> |
> |This is for DOS, not Windows.  I raised it and submitted
> |a fix.
>
> If this fix is for DOS, then I think you should take a closer look at
> DJGPP regardless of whether your EMX "works" or not.

Is there any reason why CVS can't be made portable?

Or a branch set up to achieve that end goal?  ie current
features, no known bugs, compiling on every platform
known to man, and even systems CVS has never seen
before, so long as they are at least Posix compliant?

BFN.  Paul.