Is GPC dead?
paul at redpineinstruments.org
Fri Dec 30 08:11:25 CET 2016
On 29/12/16 07:15 PM, John L. Ries wrote:
> In my humble opinion, GPC should continue to be a native Pascal compiler,
> not a translator. It should be updated to use the current GCC back ends
> (Waldek has done some of this in the past and I accept his
> characterization of the process; but I think it's necessary if GPC is to
> continue to be viable); and the goal should still be to get that aspect of
> the code completely up to date so that GPC can be added to GCC. And I
> think it highly important that it be made easy to create binary packages
> (I can probably devote some time to this, starting with a SlackBuild
> script, but it will go quicker if more than one person is doing it,
> especially since for me it would be a learning experience) and do whatever
> else can be reasonably done to get GPC into people's hands (to including
> making Linux, Windows, and OSX builds available for download from the
> website), remembering that it appears to have completely disappeared from
> Linux distros, and extant collections of UNIX toys.
I probably qualify as the least competent person here to comment. But I
am too old to worry about embarrassing myself.
Reading the comments I am left with the impression that GPC is being
left behind by ongoing changes to GCC. If that is so can a case be made
for bringing it "up to date" if it is only going to fall behind again
without constant maintenance?
Would it make sense to aim to reduce GPC's external dependencies in
order to reduce the level of maintenance required?
How much of the maintenance problem is related to trying to make GPC run
on multiple platforms? Is it worth considering reducing it to an
elf/intel only output?
Are ifdefs enemy number 1? I have just built gcc-3.4.4 and gpc20060325
on Q4OS linux. Various includes had to be found , ifdefs in rts.c dealt
with and the usual missing ctr.o files moved to get a build.
Would it be profitable to rework the code base to get rid if as many
ifdefs as possible and put all the required includes in the source
It seems that the GCC backend is also a source of considerable grief.
Could a gpc specific rtl backend be produced that was stable and didn't
require never ending maintenance?
Is it even possible to build GPC so that it would be both stable and
useful over time?
I have a libusb binding and a P2104 ( usb->serial chip ) binding, a usb
mic stereo recording pgm and a microchip pic18f programmer written in GPC.
I like the language. It is a shame it isn't used more.
Would making it a project on SourceForge make sense?
More information about the Gpc