Chapter 12.10 of the GPC docs "GPC’s Automake Mechanism – How it Works" reads as follows:
"When a program/module/unit imports (uses) an interface, GPC searches for the GPI file (see Section 12.9 [GPI files], page 476) derived from the name of the interface.
Case 1: A GPI file was found.
Each GPI file contains the name of the primary source file (normally a ‘.pas’ or ‘.p’ file) of the module/unit, and the names of all interfaces imported. GPC reads this information and invokes itself with a command like gpc foo.pas -M -o foo.d This means: preprocess the file, and write down the name of the object file and those of all its source files in ‘foo.d’. GPC reads ‘foo.d’ and looks if the object file exists and if the source was modified since the creation of the object file and the gpi file. If so, GPC calls itself again to compile the primary source file. When everything is done, the ‘.d’ file is removed. If there was no need to recompile, all interfaces imported by the module/unit are processed in the same way as this one."
I may be doing something wrong but "gpc foo.pas -M -o foo.d" doesn't give the primary source file nor the names of all interfaces imported, instead the '.d' file is always empty ....
Any clues or hints ? Full information on all unit dependencies is crucial in the project I am working on (an IDE plugin for GPC).
Regards,
Adriaan van Os
Adriaan van Os (Microbizz) wrote:
Chapter 12.10 of the GPC docs "GPCÂs Automake Mechanism  How it Works" reads as follows:
"When a program/module/unit imports (uses) an interface, GPC searches for the GPI file (see Section 12.9 [GPI files], page 476) derived from the name of the interface.
Case 1: A GPI file was found.
Each GPI file contains the name of the primary source file (normally a Â.pas or Â.p file) of the module/unit, and the names of all interfaces imported. GPC reads this information and invokes itself with a command like gpc foo.pas -M -o foo.d This means: preprocess the file, and write down the name of the object file and those of all its source files in Âfoo.dÂ. GPC reads Âfoo.d and looks if the object file exists and if the source was modified since the creation of the object file and the gpi file. If so, GPC calls itself again to compile the primary source file. When everything is done, the Â.d file is removed. If there was no need to recompile, all interfaces imported by the module/unit are processed in the same way as this one."
I may be doing something wrong but "gpc foo.pas -M -o foo.d" doesn't give the primary source file nor the names of all interfaces imported, instead the '.d' file is always empty ....
It gives the names of included files (note: preprocessor).
Any clues or hints ? Full information on all unit dependencies is crucial in the project I am working on (an IDE plugin for GPC).
That's currently not easy to obtain unless you parse the files yourself. The `gp' utility will provide such information (`--print-sources', though it doesn't help you right now ...).
Frank
Frank Heckenbach wrote:
That's currently not easy to obtain unless you parse the files yourself. The `gp' utility will provide such information (`--print-sources', though it doesn't help you right now ...).
I look forward to the 'gp' utility. Things I found to be useful for IDE integration (maybe already included);
1. a progress message at the beginning of each compiled or auto-compiled source file (maybe --print-sources does)
2. a progress message with line number at the end of each compiled or auto-compiled source file; this helps to count the total number of compiled lines (--progress-messages currently doesn't)
3. a message for each ".o" file that has been created by the compilation (maybe --print-sources does)
4. unit-dependency information (already mentioned)
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
That's currently not easy to obtain unless you parse the files yourself. The `gp' utility will provide such information (`--print-sources', though it doesn't help you right now ...).
I look forward to the 'gp' utility. Things I found to be useful for IDE integration (maybe already included);
- a progress message at the beginning of each compiled or
auto-compiled source file (maybe --print-sources does)
`--progress-messages' will do that. (This part is already working.)
(For the details of the format see http://gnu-pascal.de/contrib/frank/misc/progress-messages.tar.gz)
- a progress message with line number at the end of each compiled or
auto-compiled source file; this helps to count the total number of compiled lines (--progress-messages currently doesn't)
In the next release, `--progress-messages' and `--progress-bar' will write one message at the end (like the temporary ones). Is that what you mean?
GP will also provide for a better mechanism, allowing for a total progress bar of the whole compilation.
- a message for each ".o" file that has been created by the
compilation (maybe --print-sources does)
No, `--print-objects'. :-)
(There will also be `--print-libs' and `--print-executable'.)
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
That's currently not easy to obtain unless you parse the files yourself. The `gp' utility will provide such information (`--print-sources', though it doesn't help you right now ...).
I look forward to the 'gp' utility. Things I found to be useful for IDE integration (maybe already included);
- a progress message at the beginning of each compiled or
auto-compiled source file (maybe --print-sources does)
`--progress-messages' will do that. (This part is already working.)
(For the details of the format see http://gnu-pascal.de/contrib/frank/misc/progress-messages.tar.gz)
OK.
- a progress message with line number at the end of each compiled or
auto-compiled source file; this helps to count the total number of compiled lines (--progress-messages currently doesn't)
In the next release, `--progress-messages' and `--progress-bar' will write one message at the end (like the temporary ones). Is that what you mean?
Yes.
GP will also provide for a better mechanism, allowing for a total progress bar of the whole compilation.
- a message for each ".o" file that has been created by the
compilation (maybe --print-sources does)
No, `--print-objects'. :-)
(There will also be `--print-libs' and `--print-executable'.)
Great.
A minor issue is filename capitalization. Currently, --progress-messages and --debug-automake display auto-compiled unit filenames (and .gpi filenames) in full lowercase.
Regards,
Adriaan van Os
Adriaan van Os wrote:
A minor issue is filename capitalization. Currently, --progress-messages and --debug-automake display auto-compiled unit filenames (and .gpi filenames) in full lowercase.
Doesn't appear so (and I don't think I've changed this recently):
# cat t.pas program T;
uses FoO in 'FoO.pas';
begin
end. # gpc --automake --progress-messages t.pas #progress# FoO.pas (10) #progress# t.pas (8)
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
A minor issue is filename capitalization. Currently, --progress-messages and --debug-automake display auto-compiled unit filenames (and .gpi filenames) in full lowercase.
Doesn't appear so (and I don't think I've changed this recently):
# cat t.pas program T;
uses FoO in 'FoO.pas';
begin
end. # gpc --automake --progress-messages t.pas #progress# FoO.pas (10) #progress# t.pas (8)
With explicit unit filename:
program T; uses FoO in 'FoO.pas'; begin end.
gpc --automake --progress-messages --debug-automake t.pas checking recompilation of `FoO' in `foo.gpi': GPC automake: gpc --automake --progress-messages --debug-automake --amtmpfile=/var/tmp//ccACCt9S.gpa -M -o /var/tmp//cclbeV9K FoO.pas GPC automake: done GPC automake: adding to automake temp file: #up to date: foo.gpi all checks passed: 0 GPC automake: adding to automake temp file: FoO.o
Without explicit unit filename:
program T; uses FoO; begin end.
gpc --automake --progress-messages --debug-automake t.pas checking recompilation of `FoO' in `foo.gpi': GPC automake: gpc --automake --progress-messages --debug-automake --amtmpfile=/var/tmp//cccndV3t.gpa -M -o /var/tmp//ccJkkOUx foo.pas GPC automake: done GPC automake: adding to automake temp file: #up to date: foo.gpi all checks passed: 0 GPC automake: adding to automake temp file: foo.o
Note that compilation is too fast to test --progress-messages, but I am pretty sure that with explicit unit filename the progress-message will list "FoO.pas", without "foo.pas".
Regards,
Adriaan van Os
Adriaan van Os wrote:
Without explicit unit filename:
... GPC uses the lower-case file name. (I think we've discussed this before. Since identifiers, including unit/module names, are case-insensitive, there must be a canonical casing which happens to be lower-case. If you don't want that, you'll have to use `in'.)
Frank
At 2:35 AM +0200 12/7/03, Frank Heckenbach wrote:
Adriaan van Os wrote:
Without explicit unit filename:
... GPC uses the lower-case file name. (I think we've discussed this before. Since identifiers, including unit/module names, are case-insensitive, there must be a canonical casing which happens to be lower-case. If you don't want that, you'll have to use `in'.)
Actually, you wont have to use "in" in Mac OS X using the normal HFS Plus file system, since it is case insensitive itself, so the input files can be any case.
Enjoy, Peter.
On 12 Jul 2003 at 2:35, Frank Heckenbach wrote:
Adriaan van Os wrote:
Without explicit unit filename:
... GPC uses the lower-case file name. (I think we've discussed this before. Since identifiers, including unit/module names, are case-insensitive, there must be a canonical casing which happens to be lower-case. If you don't want that, you'll have to use `in'.)
And don't want to go down the path taken by Kylix (a.k.a Delphi for Linux) which makes the names of used units case-sensitive (a real pain, if you ask me).
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:
And don't want to go down the path taken by Kylix (a.k.a Delphi for Linux) which makes the names of used units case-sensitive (a real pain, if you ask me).
You mean: `uses foo' -> `foo.pas' and `uses Foo' -> `Foo.pas'? (As I said, this would violate Pascal's case-insensitivity, so I don't approve of it ...)
Frank
On 12 Jul 2003 at 19:16, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
And don't want to go down the path taken by Kylix (a.k.a Delphi for Linux) which makes the names of used units case-sensitive (a real pain, if you ask me).
You mean: `uses foo' -> `foo.pas' and `uses Foo' -> `Foo.pas'?
Yes. And 'program foo' -> 'foo.pas', while 'program Foo' -> 'Foo.pas'. Same with 'unit Foo', etc., etc.
(As I said, this would violate Pascal's case-insensitivity, so I don't approve of it ...)
Neither do I. It is really silly ...
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 12 Jul 2003 at 19:16, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
And don't want to go down the path taken by Kylix (a.k.a Delphi for Linux) which makes the names of used units case-sensitive (a real pain, if you ask me).
You mean: `uses foo' -> `foo.pas' and `uses Foo' -> `Foo.pas'?
Yes. And 'program foo' -> 'foo.pas', while 'program Foo' -> 'Foo.pas'.
Oh, does Delphi draw a connection between the program heading and the file name? (BP didn't AFAIR ...)
Frank
On 13 Jul 2003 at 11:19, Frank Heckenbach wrote:
You mean: `uses foo' -> `foo.pas' and `uses Foo' -> `Foo.pas'?
Yes. And 'program foo' -> 'foo.pas', while 'program Foo' -> 'Foo.pas'.
Oh, does Delphi draw a connection between the program heading and the file name?
No. I am not sure what went on with Kylix, but there were all sorts of annoying things with filenames. Perhaps I am mistaken about the program heading bit (I haven't used Kylix in a while). I might check this up ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
On 13 Jul 2003 at 11:19, Frank Heckenbach wrote:
[...]
Yes. And 'program foo' -> 'foo.pas', while 'program Foo' -> 'Foo.pas'.
Oh, does Delphi draw a connection between the program heading and the file name? (BP didn't AFAIR ...)
I just checked with Kylix (v3), and neither does it. I am not sure where I got that one from - perhaps an earlier version - but at least that is not an issue now ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
At 4:26 PM +0200 11/7/03, Adriaan van Os wrote:
With explicit unit filename:
program T; uses FoO in 'FoO.pas'; begin end.
gpc --automake --progress-messages --debug-automake t.pas checking recompilation of `FoO' in `foo.gpi': GPC automake: gpc --automake --progress-messages --debug-automake --amtmpfile=/var/tmp//ccACCt9S.gpa -M -o /var/tmp//cclbeV9K FoO.pas GPC automake: done GPC automake: adding to automake temp file: #up to date: foo.gpi all checks passed: 0 GPC automake: adding to automake temp file: FoO.o
Without explicit unit filename:
program T; uses FoO; begin end.
gpc --automake --progress-messages --debug-automake t.pas checking recompilation of `FoO' in `foo.gpi': GPC automake: gpc --automake --progress-messages --debug-automake --amtmpfile=/var/tmp//cccndV3t.gpa -M -o /var/tmp//ccJkkOUx foo.pas GPC automake: done GPC automake: adding to automake temp file: #up to date: foo.gpi all checks passed: 0 GPC automake: adding to automake temp file: foo.o
Note that compilation is too fast to test --progress-messages, but I am pretty sure that with explicit unit filename the progress-message will list "FoO.pas", without "foo.pas".
This is probably because the compiler is using the file name "foo.pas", and that is working fine because of Mac OS X's case insensitive file system. On a case sensitive file system, the compiler would presumably get an error "foo.pas file not found".
The only way for the compiler to get the right would be for it to look up the name in the directory listing, which is not something that would make sense on any other platform (at least any platform that does not have a case insensitive file system).
Probably the best solution is to look up the file name yourself to correct the case - convert the file name to an FSRef and back to a file name should probably do the trick.
Enjoy, Peter.
-
Adriaan van Os -
Adriaan van Os -
Frank Heckenbach -
Peter N Lewis -
Prof A Olowofoyeku (The African Chief)