Hi!
We're converting large (about 300 modules) project from DEC-PASCAL to GPC.
The problem is that building the project after changing some file is very time-consuming, since when I change module implementation the interface is recompiled as well.
I keep both interface and implementation in the same file, so when the file is changed I've no way telling the make what have changed - interface or implementation , don't I?
If there is an option then I can use --interface-only and --implementation-only options in gpc.
Thus number of questions :
1. Is there any "normal" way (without keeping previous version of .pas) to tell what have been changed? 2. How do you handle such problems? 3. Is there any automatic tool which can keep and provide the makefile with dependency structure of modules? The obvious way of updating Makefile manualy with steps like moduleX: moduleX_interface, moduleY, moduleZ gpc --implementation-only ModuleX
for each of 300 modules which has "thick" dependency sounds not good
Thank you in advance,
Nick
On 8 Dec 2002 at 13:39, Nick Ioffe wrote:
Hi!
We're converting large (about 300 modules) project from DEC-PASCAL to GPC.
The problem is that building the project after changing some file is very time-consuming, since when I change module implementation the interface is recompiled as well.
I keep both interface and implementation in the same file, so when the file is changed I've no way telling the make what have changed - interface or implementation , don't I?
If there is an option then I can use --interface-only and --implementation-only options in gpc.
There is: " -finterface-only" Compile only the interface part of a unit/module and exit
" -fimplementation-only" Do not produce a GPI file; only compile the implementation part
Thus number of questions :
- Is there any "normal" way (without keeping previous version of .pas) to tell what have been changed?
Writing changelogs, using CVS, etc.
- How do you handle such problems?
I use changelogs or comments in the code.
- Is there any automatic tool which can keep and provide the makefile with dependency structure of modules?
"--automake" ?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
Prof A Olowofoyeku (The African Chief) wrote:
On 8 Dec 2002 at 13:39, Nick Ioffe wrote:
Hi!
We're converting large (about 300 modules) project from DEC-PASCAL to GPC.
The problem is that building the project after changing some file is very time-consuming, since when I change module implementation the interface is recompiled as well.
I keep both interface and implementation in the same file, so when the file is changed I've no way telling the make what have changed - interface or implementation , don't I?
If there is an option then I can use --interface-only and --implementation-only options in gpc.
There is: " -finterface-only" Compile only the interface part of a unit/module and exit
" -fimplementation-only" Do not produce a GPI file; only compile the implementation part
Thus number of questions :
- Is there any "normal" way (without keeping previous version of .pas) to tell what have been changed?
Writing changelogs, using CVS, etc.
I suppose Nick meant how to tell the compiler (or the make tool) ...
- How do you handle such problems?
I use changelogs or comments in the code.
- Is there any automatic tool which can keep and provide the makefile with dependency structure of modules?
"--automake" ?
The problem with `--automake' is that it consideres any modification of the file a reason to recompile everything that depends on it (so it tries to be too conservative in doubt).
The often-announced `gp' utility will solve this (by keeping a checksum of the interface). But, as I said before, it's not finished yet (in particular, it doesn't work with modules yet, only with units).
This might be another reason to make the release of gp a higher priority. But I don't think I'll be able to finish it this year. BTW, what's your time scale, would it still be useful to you some time later, or will you have to find another way then, anyway?
Frank
Prof A Olowofoyeku (The African Chief) wrote:
On 8 Dec 2002 at 13:39, Nick Ioffe wrote:
We're converting large (about 300 modules) project from DEC-PASCAL to GPC.
The problem is that building the project after changing some file is very time-consuming, since when I change module implementation the interface is recompiled as well.
I keep both interface and implementation in the same file, so when the file is changed I've no way telling the make what have changed - interface or implementation , don't I?
If there is an option then I can use --interface-only and --implementation-only options in gpc.
There is: " -finterface-only" Compile only the interface part of a unit/module and exit
" -fimplementation-only" Do not produce a GPI file; only compile the implementation part
Thus number of questions :
- Is there any "normal" way (without keeping previous version of .pas) to tell what have been changed?
Writing changelogs, using CVS, etc.
I suppose Nick meant how to tell the compiler (or the make tool) ...
- How do you handle such problems?
I use changelogs or comments in the code.
- Is there any automatic tool which can keep and provide the makefile with dependency structure of modules?
"--automake" ?
The problem with `--automake' is that it consideres any modification of the file a reason to recompile everything that depends on it (so it tries to be too conservative in doubt).
The often-announced `gp' utility will solve this (by keeping a checksum of the interface). But, as I said before, it's not finished yet (in particular, it doesn't work with modules yet, only with units).
This might be another reason to make the release of gp a higher priority. But I don't think I'll be able to finish it this year. BTW, what's your time scale, would it still be useful to you some time later, or will you have to find another way then, anyway?
Frank
[... deleted...]
The problem with `--automake' is that it consideres any modification of the file a reason to recompile everything that depends on it (so it tries to be too conservative in doubt).
The often-announced `gp' utility will solve this (by keeping a checksum of the interface). But, as I said before, it's not finished yet (in particular, it doesn't work with modules yet, only with units).
This might be another reason to make the release of gp a higher priority. But I don't think I'll be able to finish it this year. BTW, what's your time scale, would it still be useful to you some time later, or will you have to find another way then, anyway?
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
Hi!
After playing with automake I have to say that `gp' utility will be very usefull. And it doesn't matter when it will arrive. But automake would be usefull if the following bug will be fixed: I use the Extended Pascal syntax for interface and implementation. Sometimes I need to import modules in implementation only. The problem is that when I change the imported module and recompile with --automake nothing is compiled in module which imports the changed one in implementation only.
Example: ------------- mod1.pas ------------------ module mod1 interface; export mod1 = all; procedure mod1_write; end. module mod1 implementation; procedure mod1_write; begin writeln ('mod1.mod1_write'); end; end. -------------- mod2.pas ---------------------- module mod2 interface; export mod2 = all; procedure mod2_write; end. module mod2 implementation; import mod1; procedure mod2_write; begin mod1_write; end; end. ------------------- main.pas -------------------- program main (input,output); import mod1; import mod2; begin mod1_write; mod2_write; end.
Now I change mod1_write to accept string parameter and change nothing in the rest of the files gpc --automake main.pas causes me to change the mod1_write invocation in main.pas line 5. When I change it I succeed to build new a.out and when I run I fail with Segmentation fault after the first print trying to invoce the mod1_write from the mod2.
I still use 20020510 gpc build but no bug concerning `-automake' has been fixed since then!
Regarding the automake "conservativity" - I find it usefull to allow split of interface and implementation in different files. Then change of the implementation only will not cause the recompile of the whole project. The gpc user workflow would be like this: 1. change the implementation (say mod1.pas) 2. recompile - gpc -c mod1.pas (important - in case of implementation only only mod1.o should be changed) 3. relink the project.
If interface was change then : 1. recompile the interface file (say mod1_.pas) 2. recompile the project with gpc --automake project_main.pas
This way ADA environment works on VMS systems and I find it very usefull. Actually its' (ADA) smart recompile is much much smarter - it can recognize whether the objects used in importing module (package in ADAish) had been changed in imported module interface and thus decides what should be recompiled.
I think it is the best you can get and somehow too much. Say it would be nice to have but I'd be glad if the decisions would be on the level - used interface changed so recompile is needed and when I recompile the module and the interface remains the same - it causes no further recompile.
I hope it was clear enough and if not then I can explain myself better...
Meanwhile I'll have to find some workaround, but as soon as `gp' will see the sun-light I'll use it!
Nick
Frank
Two questions about the "gp" utility;
1. Is it being written in Pascal or in C? (I hope it is the former) 2. Will it be able to use a cfg file in addition to taking arguments from the command line?
Thanks.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
Prof. A Olowofoyeku (The African Chief) wrote:
Two questions about the "gp" utility;
- Is it being written in Pascal or in C? (I hope it is the former)
Yes, mostly. But some parts use flex and bison (which generate C code), and share a few definitions (such as lists of options) with the compiler sources. But the most parts are being written in Pascal.
- Will it be able to use a cfg file in addition to taking arguments
from the command line?
Yes.
Frank
On 12 Dec 2002 at 16:29, Frank Heckenbach wrote:
[...]
- Will it be able to use a cfg file in addition to taking arguments
from the command line?
Yes.
Excellent! Can I put in a request at this stage? Please endeavour to make the configuration file trivial to use (e.g., as simple as BP's old tpc.cfg files) and certainly not anything complex (such as the syntax for Makefiles or specs files).
Thanks.
PS: if you want testers for alphas or work-in-progress, please count me in.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
Prof. A Olowofoyeku (The African Chief) wrote:
On 12 Dec 2002 at 16:29, Frank Heckenbach wrote:
[...]
- Will it be able to use a cfg file in addition to taking arguments
from the command line?
Yes.
Excellent! Can I put in a request at this stage? Please endeavour to make the configuration file trivial to use (e.g., as simple as BP's old tpc.cfg files) and certainly not anything complex (such as the syntax for Makefiles or specs files).
My plan is to make is complex to make it simple. :-) I.e., provide a flexible configuration language that allows redefining options, so one can, e.g., write a config file that translated BP-style options (or another style) to GPC options. This would be a one-time effort, and normal users who like BP-style options could use this config file and write their options in BP style.
The syntax for the config language will be quite similar to Pascal (not like specs ;-).
PS: if you want testers for alphas or work-in-progress, please count me in.
Fine. Of course, I'll annouce the first alpha on this list.
Frank
-
Frank Heckenbach -
Nick Ioffe -
Prof A Olowofoyeku (The African Chief) -
Prof. A Olowofoyeku (The African Chief)