At 12:26 AM +0100 4/3/03, Frank Heckenbach wrote:
Grant Jacobs wrote:
At 1:22 PM +0100 3/3/03, Frank Heckenbach wrote:
Grant Jacobs wrote:
- The compiler won't make .o files for units that are found in a
directory other than the one you're compiling from.
I have three directories and I compile from within one of them. The units in the other two directories are located using --unit-path compiler option. Reading the docs, I'm under the impression its supposed to default to placing the .o files into the directory you compile from for all units,
Yes, I think that's how it should be (and seems to be in my test).
regardless where the units are located unless you play with the compiler options. The .gpi files *are* made correctly. (I'm using --autobuild, btw.)
Sorry, but your description is not really clear to me. Are no .o files created, or in which directories are they created, and what about the gpi files? Which compiler options did you use, and which files are located where?
No .o files are made for nits which lie outside the current directory. You have to do them yourself manually, which in my case is simply a matter of 'gpc -c ../otherdir/*.p'. However, its not what I expected. I thought the compiler would locate them via --unit-path which I use on the command line, etc.
alias gpc="gpc --executable-file-name --nested-comments
--unit-path='~sysadmin/work/code/LMBCodeArchive/GNUPascal/GHJLibraries:~sysadmin/work/code/LMBCodeArchive/GNUPascal/table_code_dir:.' --autobuild"
(Excuse the wraparound.) I compile from ~/sysadmin/work/code/LMBCodeArchive/GNUPascal/aa_prog_dir
The units in GHJLibraries and table_code_dir have their .gpi files made into aa_prog_dir as expected; but no .o files are made for these units. .o files are made for all the units in aa_prog_dir, but not the other two directories.
I can work around it, but it might be worth noting as something that might be tackled "one day".
If really no object files are generated, this would be a rather serious bug.
No .o files for those units in other directories, even though their .gpi files are present. And the are not built into the other directories either. For the units in the current directory, all the .o files are made.
Can you send me the output of a full (i.e., `--autobuild', or after removing all .gpi files) compilation with `-v' (verbose), with a preferably simple example that exhibits this bug?
I'll try get onto this, but basically its just a list of linker errors; all of which are unresolved references to the routines the units in the current directory need from the units found in the other directories. Since their .o files are not present, that's not surprising! I'm not really sure what you'd learn from that.
As for removing all the .gpi files, I have to admit I'm reluctant! In a post I haven't sent to you I was going to point out that --automake (or --autobuild) in my hands doesn't work if the .gpi files aren't present. So the first time around I'm forced to compile everything by hand (or make up a make file which I haven't done yet).
This is particularly annoying on the odd occasion when I change a unit only to find that the compiler now complains about wanting to 'recompile unit XXX in the proper order' despite the fact I've only changed one unit. The only work-around I've found so far is to trash all the .o and .gpi files and start over.
Here's the contents of that post:
I was trying to fix my linking problems, when I ran into a possible reason why --automake or --autobuild isn't doing its thing for me. Its seems that if the .gpi file is not present for a unit, it won't compile that unit in, but rather stops saying that that unit could not be compiled, eg.
module/unit `ghj_aaclustergroups' could not be compiled
This means the first time around I'm force to compile the lot myself. I've sort-of ducked by this using gpc -c *.pas a few times.
Thinking about it, is this because the compiler can't guess the filename holding the unit, given that the unit name is assigned within the file?
If so, a possible extension would be to do one scan of all *.pas and *.p files at the onset and compile a table of unit/module names for each file and proceed from there? Or perhaps this is what it already does and something else is afoot?
I know you want to deal with automake later, separately from the compiler but I thought I'd mentions this while its at hand.
BTW, if your shell behaves like Unix shells, then the above alias is probably wrong, because `~' within single quotes is not expanded, i.e. it would look for a directory actually called `~sysadmin' (rather than the home of user `sysadmin'). But I don't suppose that's the problem here since apparently the units are found.
I use bash.
Grant