Morten Gulbrandsen wrote:
I found no binary for FreeBSD on your homepage, However I found this gpc-2.0_1 A free 32-bit Pascal compiler Long description | Sources | Main Web Site Maintained by: antonz@library.ntu-kpi.kiev.ua Requires: autoconf213-2.13.000227, gcc-2.8.1, gettext-0.10.35, gmake-3.79.1, m4-1.4_1
Probably not. However, you can find the current sources as a tar.gz archive and on the CVS server.
I can probably make binary snapshots from CVS once in every two weeks without problems, if the build process works usually.
next release which will incorporate these changes. Our sources are currently updated once in a few weeks. When FreeBSD ports are updated, I don't know.
That depends on
1) the maintainer (the one who sends requests to the FreeBSD committers) 2) the backlog of the committers themselves.
2) is a serious problem, and they often have a backlog of several weeks afaik. The same applies to Debian. The time between submitting and actuallisation can be quite long afaik. (FPC experience, not GPC) SUSE is quite fast OTOH.
I don't know who made up the version 2.0_1. Perhaps a numbering used by the FreeBSD ports. 2.0 was the last "official" GPC release (many years ago, 1996 or so). 2.1 will be the next one, coming soon. In the meantime, we just use dates.
Often FreeBSD adds some digits to signal the revision of the port. This because the port can apply patches to fix FreeBSD specific problems (both functional and with building)
So if 2.1 is the GPC release 2.1p1 signals revision 1 of the port (port-makefile +patches), p2 the second etc.
After the release of 2.1, we'll try to get binaries there for as many systems as possible.
Or at least a README.FreeBSD
Why? AFAIK, there's nothing special WRT FreeBSD, compared to other Un*x systems. Compiling from the sources should work just the same.
FreeBSD is the system that most closely resembles Linux. If something works on Linux, and is not based largely on specific kernel revisions, it should be able to work in native mode too.
I had some problems with the terminal driver though. (accessing "special" display functions not defined by vt<xxx>)