Waldek Hebisch wrote:
Frank Heckenbach wrote:
Basically because "everybody" does it, i.e. each frontent has its own such driver AFAIK. But that's not a coercing point, of course. And, as I said, we could still offer the (current) gpc driver (without automake) under another (and even longer, AFAIC ;-) name.
You many times mentioned removing automake. I think you are too fast here.
Sorry, but this has been discussed (and decided) for years. It can't really be called too fast.
As I understand main problems with automake are:
- bugs
- maintenance
IMHO the main remaining bug is that gpc writes to GPI files after compiling interface. That bug affects `gp' too. Both automake and `gp' try to workaround that, but the real fix is to write implementation info in another place (for example a new GPI file).
Why do you think this is a bug, and where do you think gp tries to work around it? (In fact, gp doesn't even look at the contents of GPI files. It looks at the timestamps, but that's more like an additional paranoia check.)
Concerning maintenance I do not think the cost is so big, and one part (updating `gpc' driver) ATM is "paid" for next few months.
IIRC, about half of your recent patch is for the driver (the other half are qualified identifiers and other substantial features), and that's only for gcc-3.3.x->3.4.0. If that's not a big cost, I don't know.
And there are additional kludges in module.c (and smaller parts in other source files). You might not have had to work on this code yet, but I had to, many times, and the code is very fragile.
And that's where the real automake bugs are AFAIK. Currently I made it recompile too much rather than too little (which is bad for efficiency, and we don't even talk about checking file contents (MD5 sums as GP does) instead of just timestamps), and still it might miss some recompilations (didn't check exactly, and such situations are very tricky to debug and unnerving -- I had to do this a number of times). The core problem is that is has only local information (about the current module and its dependencies).
Besides, calling the gpc driver (recursively) from the compiler proper (gpc1) is not really in the intention of this design. So far it's seemed to work (or more precisely, we've just copied the necessary parts, pexecute etc., from gpc to gpc1), but I don't know if it won't break with some GCC version. Also, recursion is more memory hungry than iteration (as done by "GP", or make FTM).
I am somwhat affraid of effort to maintain `gp'. I gave only short look over the sources and I did not give it real trial. However, from your comments I understand that ATM `gp' misses some automake features.
Which ones?
BTW, since GP is written mostly in Pascal, it should be easier for many people to maintain it when necessary. (At least from the negative comments I've often seen about GPC being written in C.)
Also, I am somewhat concerned by the `gp' parser (you use flex to implement it, but conceptually it is a parser).
Yes.
In fact, it is not clear that in GNU Pascal one can find names of imported interfaces/units without looking at all of imported interfaces.
I'm not sure exactly what you mean. If a program says `uses foo;' or `import foo;', the name of the imported unit/interface is `foo'. Do you mean the file name (it's `foo.{pas,p,...}' unless `in '...'' is given etc., that's the same for automake)? Or do you mean names of indirectly imported interfaces (they're stored in gpd files etc.)?
And, of course, GP does look at all of the imported units/modules (either their .gpd files if existing and up to date, or their source code). It just does it in a cleaner (IMHO) way, file by file, rather than recursively intermixed (and often duplicated) as automake.
The problem is that parsing requires to know what a keyword is and many keywords are "weak" -- they may be redefined (also in imported interfaces!). Frank, you probably analysed that, but assumptions needed for `gp' to work should be written up.
Yes. In fact it may fail in some very strange cases (very crude mixtures of dialects, I doubt whether they'd ever occur in practice).
But this parser is only a small part of gp and easy to fix/rewrite. In fact, I'm thinking about using the real GPC parser -- either as a special mode to GPC itself (comparable to `-E' for the preprocessor which lists dependencies only), but it might be too much effort to "do nothing" in many places; or just taking the bison parser and removing everything unrelated (which will be a lot, including most semantic actions, so a rather simple parser remains). I think that's not a big deal, but before I do anything about it, first I want to integrate the GPC preprocessor because this may influence things.
And some time is needed to asess if changes to GNU Pascal language will not invalidate those assumptions.
Sure, changes that affect the import and export syntax could, but again, that's not a big deal. Adding a few rules to the parser (whether flex based as now, or bison based) is a matter of minutes (maybe less than it takes me to write this mail) and I expect it to happen very rarely.
So IMHO we need few months (or a year) for `gp' to stablise _before_ we can depreciate automake. And I think that we should have a year of depreciation before removal.
We can discuss time scales. I'd like to have automake deprecated in gpc-2.2, but I don't know when gpc-2.2 will be released (maybe next year).
For now, I'd like people (who used automake) to try GP in order to see if there are fundamental problems with it in practical use. This will take some months at least, of course, until we can be sure, and during this time, GP should also stabilize (as the few bugfixes in the last two weeks have already shown) ...
Frank