[nhc-bugs] The nhc98 package for NetBSD (update to 1.18)

[Jesper Louis Andersen]

I assume this is the correct mailing list to send a report of my workings
on nhc98 to get an updated NetBSD port. It is sent CC to since he is the
current nhc98 maintainer of the NetBSD package in the NetBSD pkgsrc tree.

I am reporting on a number of issues with the package. The rationale for this
report is to inform various parties of the problems I have encountered, so
they can be thought of in later releases. As a consequence the emphasis of
this mail will target the build system, the system infrastructure at york(!)
and interfacing with NetBSD in general. Communication often makes the 
difference between a success and failure when porting software. I also hope
Krister does not feel I have hi-jacked his work.

A NetBSD package is a Makefile, along with some helping files. The makefile
accepts a number of targets which fetches the source code, configures it for
NetBSD, patches the sources, compiles the program and installs the program in
such a way it can be easily deleted again. The approach is different from
binary package distribution, but is equal to other Operating systems, noteably
the *BSD family and Gentoo Linux. 

The first problem with updating the package is the retrieval phase. This is 
done by a program, ftp(1), which will try to fetch the file 
ftp://ftp.cs.york.ac.uk/pub/haskell/nhc98/nhc98src-1.18.tar.gz. Unfortunately,
this fails because the york ftp-server and ftp(1) agrees on entering
Extended Passive Mode (EPRT and EPSV as per RFC 2428) which I then suspect the
york firewall to disallow. Note that programs such as FreeBSDs fetch(1) and
wget(1) of GNU chooses not entering EPRT/EPSV mode; thus having no problems
fetching the source code.

The direct solution to this problem would be to fix the firewall. We could
add a workaround into the packages fetching process, but this has a number
of implications. First, it is not the correct solution to the problem. Second,
the fetching is generalized and not necessarily done by ftp(1). Altering
the options given to the ${FETCH_COMMAND} is not portable if another 
retrieval program is chosen.

The obvious way to bootstrap nhc98 would be by gcc. Unfortunately, NetBSDs
package tree can select the compiler to be something other than gcc. The
reason is the portability of NetBSD. If running on another architecture than,
say i386, one could choose a native compiler over gcc for compilation. As a
consequence $(CC) is set to be ``cc'' when compiling the nhc98 Makefile; not
``gcc'' as expected. My crude solution were to oversteer $(CC) and substitute
it for ${BUILDCOMP}, see patches further down. This leads to my question:

Can nhc98 be compiled by anything else than nhc98? Have you tried? I can
alter the package to constrain itself to certain compilers in the case of
impossibility.

The next problem I ran into in the upgrade process from 1.16 is a number of
old patches we put on the source code before compiling. The patches are
all laid out at the following url:

http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/lang/nhc98/patches/

I will write [aa] for patch-aa, [ab] for patch-ab and so forth. Here is my
findings. [aa] concerns an addition of $LDFLAGS to the curses compilation. This
is done because the NetBSD package system can set further linker directives
in this variable and we need to honour them. [ab] concerns an errornous way
of calling abort(3). This is fixed in 1.18 and can go away. [ac, ad, af, ag]
are all patches from the nhc98 homepage for nhc1.16. These are obviously not
needed for 1.18 and can go away. [ae] does not seem to apply anymore. I am
on a -current NetBSD and had no build problems. [ah] adjusts for $(CC) by
substituting it for $(BUILDCOMP). I think this is the correct solution, so
I have adapted that one.

That is all. Unless I get complaints from any department - I will submit
a change to the NetBSD bug-tracker in a couple of days.

-- 
jlouis