CBFalconer wrote:
Frank Heckenbach wrote:
Grant Jacobs wrote:
As I said, I don't think "make" is a good thing to think of for a *normal* Pascal programmer. We're, of course, deep in the internals, but a normal programm doesn't want to (and shouldn't have to) think about when a compiler recreates which files. It should just produce a correct executable.
You could try keep it all within gpc as so not to generate another name that could conflict. Make gpc itself a small program that manages whatever programs do the actual work.
That's what the program in question ("GP") actually is. (So, as I suggested, we could rename the existing gpc executable and call this one gpc. But I'm not sure yet, because it is an incompatible change ...)
But that is what gcc is doing already, except it is orchestrating between various languages to arrive at a common executable format. Meanwhile it is involving such diverse programs as 'as', 'ld', etc.
But in a "C-ish" way: compile a single file, don't care about dependencies etc.
Keep in mind that automake is a kludged-on extension that never worked correctly (and probably never could). It's served its time more or less well, but it isn't a workable solution for the future.
IMO the thing that is missing in GPC is clear instructions as to how to run individual compiles etc. for systems that include units and/or modules and/or libraries. Saying "use -automake" does not cut it. Of course, that seems to be exactly the problem you are trying to solve, but hiding the machiniations behind yet another supervisory program does not fill the bill to my mind.
Why not, if I may ask?
I would rather see a program that scans the various sources, starting from the named one, and creates a make file for use by gnu make. This is more a Unix philosophy than a C one.
I had thought about it before starting work on "GP", but came to the conclusion that it didn't really work out. As Waldek explained recently, the creation of both .gpi and .o files doesn't really fit with the make idea (single destination), and any possible work-arounds would at best be kludges.
Besides, not using make, we could be a bit more clever, e.g. not recompile a module [interface], if the module [interface] text is unchanged, even if the file was updated. make can't do this without big kludges (more external programs, timestamps and what not).
(Another thing is that we save one step by doing "GP -> gpc" rather than "GP -> make -> gpc", but that's a minor point.)
After that a simple script or bat file should be able to replace YASP.
I (had?) hoped that we could do without that, especially since "GP" is meant to add some config file and options translation mechanism, so that indeed a user could, after initially setting things up to this taste, just do `gp myprog' in almost all cases. That's also why I'd like to have a short name (not least because that's what I intend to use myself. Currently I do use scripts/aliases around `gpc', but I hoped to get rid of that with "GP" in place).
Pascal is a simple language, using it should also be simple.
While there may be debates on the first part (the module concept and other EP features really have some nontrivial aspects ;-), I agree on the second part, see the previous paragraph. (And the plain gcc/gpc interface, especially when automake is removed, certainly doesn't do that.)
BTW, I wonder if we need the (current) gpc executable at all then. I'd have to check exactly, but maybe it wouldn't basically do more than the equivalent of `gcc -lm -lgpc' (and give some different help output etc.). If we teach "GP" to pass `-lm -lgpc', we could get rid of the separate gpc executable and call "GP" gpc. But I'm not sure if everybody would be comfortable with such a change ...
Frank