bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: different CVS_SERVER for different hosts


From: Paul Edwards
Subject: Re: different CVS_SERVER for different hosts
Date: Fri, 31 Oct 2003 14:56:31 GMT

"Derek Robert Price" <derek@ximbiot.com> wrote in message 
news:mailman.2878.1067607774.21628.bug-cvs@gnu.org...
> |>CVS can still be compiled on Windows under CygWin using GCC or under
> |>MSVC.
> |
> |Really?  Is that just missing from the Windows/NT README then?
> |Do you know what the procedure for compiling is?
>
> There are already notes in INSTALL & in windows-NT/README about
> compiling with MSVC (Microsoft Visual C++).  I just assumed that people

I just assumed from those notes that that was the only C
compiler supported for Windows.  :-(  :-)

> would know that the CygWin procedure was the same as the UNIX procedure,
> as that is one of CygWin's design goals.  It might deserve a note or two
> that it works.

I have the Cygwin compiler, I don't know that I have any of the
other stuff.

I know I can compile C programs using the GCC compiler that
came with Cygwin.

The Unix procedure is to go ./configure.

Even though I have the cygwin compiler, I can't run ./configure,
because I am in a DOS shell.  I can run a batch file though.

However, it just so happens that I happen to have bash
installed too.  But when I go

"./configure"

it says "no such command" or somesuch

But I just had a brainwave.

I typed in "sh ./configure" and then it all started up.

However, I notice that there are a lot of cases of
"File not found" etc.

> |>We can't fix bugs and inconsistencies without bug reports and bug
> |>reports can be hard to verify without exact hardware and software
> |>combinations.
> |>
> |>If you'd like to buy me the computers w/your desired operating systems
> |>and pay for my time, I'd be happy to set up nightly testing on whatever
> |>platforms you like.
> |
> |The platform is an arbitrary and unspecified platform that is
> |100% ISO C conforming and 100% Posix library conforming.
> |
> |It doesn't have any Unix-like shell.
> |
> |So long as the application itself conforms to the two applicable
> |standards, it should compile out of the box.  At least each
> |source file should compile anyway (in the same way that a
> |"hello, world" program will compile).  I don't mind writing a
> |batch file to compile each source file in turn and then linking
> |it at the end.
>
> Obviously we've never encountered such a platform before, but you bring

This platform is fully described in the POSIX.1 standard
and in the C89 standard.

> up an interesting point.  Compiling is now mostly dependant on running
> configure to set the variables, but the code could be designed to be
> more biased towards POSIX - so that it would compile _without_ running
> configure on a pure POSIX system.

Yes, correct.  That's exactly what I expect as part of
portability, not a shell script which doesn't conform to
either C89 nor POSIX.1.  C is meant to be the portable
language, not shell script!!!  C does in fact go a long way
towards portability.  But shell scripts completely
obliterate that progress!

I would expect something like rcs to compile on any C89
platform.  Just by typing in "bcc" or "wcl" or any of the
hundreds of 100% ISO conforming compilers.

I would expect CVS, since it is not really practical to make
it C89 compliant, but it is practical to make it Posix compliant,
since the only thing that CVS should need beyond C89 is
directory operations.  At least to work locally.

Yuck!  Bash has just reported to me that it needs a default
text editor.  No it shouldn't!  I don't mind if CVS gives me
an error when I do a commit, saying "-m is mandatory on
your system", but I do mind when it requires me to have
some callable editor.  This is another thing that takes
away the portability.

> configure has always worked fine for me, so I'd never really considered
> it, but it is certainly an interesting concept.  Feel free to submit
> patches!

Ok, I will see if I can submit a config.h that basically deletes
anything that is not POSIX.

> As a workaround, the config.h in the EMX subdirectory might get you most
> of what you want, since that is basically what configure creates under
> UNIX.

When I realised the EMX directory existed, I tried using
that, by copying it into multiple directories (the instructions
were not correct), but that still didn't work, complaining
about fnmatch.h or something.

> Alternatively, you could run configure on some platform that will
> enable most of the POSIX compliant functions, like Linux, and start with
> the config.h that that generates.  There should be less to edit that way.
>
> If EMX is really 100% POSIX compliant these days, you might be able to
> get away without using most or all of the rest of the code in the emx
> directory if you set up config.h correctly.

Ok, I'll see how I go.

Thanks for at least raising the possibility that CVS might actually
compile on my "rare" Win 98 + gcc system.  I must say I thought
it quite strange that gcc did not appear to be supported under
Win 98 for CVS.

BFN.  Paul.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]