Newsgroups: comp.sys.amiga.programmer
Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!ists!newshub.ccs.yorku.ca!nexus.yorku.ca!shields
From: shields@nexus.yorku.ca (Paul Shields)
Subject: Re: RCS (and porting GNU stuff)
Message-ID: <1991Jun12.081252.11729@newshub.ccs.yorku.ca>
Sender: news@newshub.ccs.yorku.ca (USENET News System)
Organization: York University
References: <1991Jun11.224756.18225@sol.UVic.CA>
Date: Wed, 12 Jun 1991 08:12:52 GMT

denhaana@sol.uvic.ca (Albert Den Haan) writes:
> I ftp'ed the RCS implementation from ab20
>last week in hopes of getting the same facilities on my amiga.  No such luck.

I'd love a working RCS for Amiga.

[...]
>My second question (how many is that so far, really?) is how does one
>go about porting a GNU program/system to the Amiga platform?  The SAS C
>run-time library has quite a few UN*X 'compatible' functions but where
>does most of the effort appear? 

I haven't ported any Unixy/Gnuy stuff to Amiga. But I have tried porting
such programs to MS-DOS.   The issues are usually:

 - processor .. though 680x0-based Unix's are common, issues like 16/32 bit
   int's come into play.

 - compiler .. the choices seem to be SAS or Manx.  Portable programs
   strictly conforming to ANSI C should not break the compiler, but they
   do anyway.  Compiler bugs may break code in statements or macros that
   are fairly complex.  This forces you to exercise all of the code to 
   verify that it works the same under Amiga as Unix, so extensive testing
   is necessary.  Good run-time debugging facilities are helpful, as is
   having a Unix machine around to compare behaviour.

 - operating system calls .. Amiga O/S calls are not very
   helpful.  Semantics of the filesystem may differ enough to cause
   problems.  Environment variables differ radically.  Process
   creation mechanisms differ radically: fork(), exec(), system(), popen()
   may not be present and may be broken.  Many programs (probably
   RCS, too) execute a fork() then exec() a Unix command in the
   child process.  Managing something as simple in Unix as pipes can
   become a nightmare.

 - run-time libraries .. depend on what comes with the compiler and
   are by no means complete. this was the biggest factor porting to
   MS-DOS.  standard functions and whole systems available in all Unix's
   were not present, like regexp, dbm, curses, and termcap.  Several, 
   like open(), ioctl(), had weirdly different semantics which didn't
   match Unix and broke instantly.

 - programming environment infrastructure.. the makefiles for the Unix
   programs often assume the existence of other programs which have not 
   been ported, and assume the compiler has a standard set of switches.
   patch, unshar, uudecode, tar, compress, and ed often are necessary for
   applying patches.  The software itself may require that "standard" 
   commands (sh, ed, sed, grep, sort, awk, date, dc, wc, etc.) be present
   in order to work..  And it's vital that those must work exactly as 
   expected.


...And now a complaint to the programming community, some of 
which doesn't seem to have this down yet:

   If you make an Amiga (or MS-DOS) port or workalike of a Gnu or Unix 
   command which is a software building block, then you can't change
   its features.  Otherwise the porting curve for other software is 
   too steep.

   If you PD or sharware any such tool, PLEASE don't restrict its
   use, and PLEASE release source.. so that when somebody discovers
   that the program is broken, they don't have to come back to you 
   to support it.

thanks,
Paul Shields
shields@nexus.yorku.ca