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 directory?
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?
Regards,
Paul Isaacs