Hi all,
I try to use gp to build my programs and have trouble with Pascal sources using c parts. When invoked by gp, gpc stops where I put {$L source.c} saying "error: file 'source.c' must be compiled. I remarked that gpc is called with --no-automake in its options list, even if I put --automake on gp command-line. This prevents the compilation of the c sources prior the Pascal module. My question is: Is the --no-automake passed to gpc causing the problem or is it because gp should compile the c sources before the Pascal module?
I applied all the recent patches to gp but with no success on this particular problem.
Also, I solved the problem of link with external libraries with gp by processing the dependencies list before the command-line options in routine StartPipe(). This works well. If you are interested by the modification I can send it. Although I don't know which tool you use to make your diffs, I an ready to learn it. Let me know.
Regards
Pascal Viandier pascal@accovia.com
Pascal Viandier wrote:
I try to use gp to build my programs and have trouble with Pascal sources using c parts. When invoked by gp, gpc stops where I put {$L source.c} saying "error: file 'source.c' must be compiled.
I thought this was solved by Peter's patch (my and your message of the day before) ?
I remarked that gpc is called with --no-automake in its options list, even if I put --automake on gp command-line. This prevents the compilation of the c sources prior the Pascal module. My question is: Is the --no-automake passed to gpc causing the problem or is it because gp should compile the c sources before the Pascal module?
gp replaces --automake (and --automake will disappear in the future) so there is no point in passing --automake (and --no-automake is the default for gpc anyway).
I applied all the recent patches to gp but with no success on this particular problem.
I am puzzled. Is this reproducable somehow ? Or what does Frank say about it ?
A workaround might be to compile the C stuff through a Makefile and then link the produced .o files (or the one .a file) to the gpc program (see e.g. http://gpwiki.org/index.php/Make for an excellent tutorial on Makefiles).
Also, I solved the problem of link with external libraries with gp by processing the dependencies list before the command-line options in routine StartPipe(). This works well. If you are interested by the modification I can send it. Although I don't know which tool you use to make your diffs, I an ready to learn it. Let me know.
The "diff" command line tool produces diff files (type "man diff" for the manual), e.g.
diff -u gp.pas.orig gp.pas > gp.mypatch.diff
and the "patch" comand line tool applies them (type "man patch" for the manual) e.g.
patch -p0 < gp.mypatch.diff
Regards,
Adriaan van Os
Adriaan van Os wrote:
gp replaces --automake (and --automake will disappear in the future) so there is no point in passing --automake (and --no-automake is the default for gpc anyway).
More precisely, GPC's default is autolink, and --no-automake also implies --no-autolink, so it does make a little difference (though it should not with -c which gp usually passes).
I applied all the recent patches to gp but with no success on this particular problem.
I am puzzled. Is this reproducable somehow ? Or what does Frank say about it ?
I'd also need a reproducible case. All I can say is that I successfully compile with gp project that use {$L foo.c} directives.
BTW, you do use a different base name for Pascal and C files (e.g. foo.pas and fooc.c)? Using the same base name would result in object files of the same name, and so cannot work.
The "diff" command line tool produces diff files (type "man diff" for the manual), e.g.
diff -u gp.pas.orig gp.pas > gp.mypatch.diff
I'd like to stress the `-u' option. The default output format (without this option) is less well suited. `-c' instead of `-u' is also acceptable, though IMHO less readable, so we use it only when compatibility to various versions of patch is required (some of which don't understand `-u' format diffs).
Frank
-----Message d'origine----- De : gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] De la part de Frank Heckenbach Envoyé : November 30, 2005 11:48 À : gpc@gnu.de Objet : Re: gp vs --automake
Adriaan van Os wrote:
gp replaces --automake (and --automake will disappear in the future) so there is no point in passing --automake (and --no-automake is the default for gpc anyway).
More precisely, GPC's default is autolink, and --no-automake also implies --no-autolink, so it does make a little difference (though it should not with -c which gp usually passes).
I applied all the recent patches to gp but with no success on this particular problem.
I am puzzled. Is this reproducable somehow ? Or what does Frank say about it ?
I'd also need a reproducible case. All I can say is that I successfully compile with gp project that use {$L foo.c} directives.
I am working on that to give you a clear example of what happens. I made a simple test program using a module that contains the {$L } directive and gp worked perfectly, even recompiling the c source when necessary. But with the real life application it fails repeatedly. I am trying to find the pattern and will let you know.
BTW, you do use a different base name for Pascal and C files (e.g. foo.pas and fooc.c)? Using the same base name would result in object files of the same name, and so cannot work.
I hit this problem at the very beginning of the port from SUN Pascal. Now the Pascal anc C sources have distinct base names.
The "diff" command line tool produces diff files (type "man diff" for the manual), e.g.
diff -u gp.pas.orig gp.pas > gp.mypatch.diff
I'd like to stress the `-u' option. The default output format (without this option) is less well suited. `-c' instead of `-u' is also acceptable, though IMHO less readable, so we use it only when compatibility to various versions of patch is required (some of which don't understand `-u' format diffs).
Thanks. I have never used the diff "-u" option (nor patch either. I applied the patches by hand :-( ). Anyway, here is the diff:
--- gp.pas.orig 2005-11-30 12:47:37.000000000 -0500 +++ gp.pas 2005-11-30 10:49:29.000000000 -0500 @@ -649,9 +649,14 @@ e := 0; OptionCount := Compilers[PascalFlag].OptionCount[OptionSelection]; New (Parameters, e + OptionCount + n - m + 1); + { First, needed options } for i := 1 to e do Parameters^[i] := NeededOptions^[i]; - i := e; + { Then the list of dependencies } + for i := 1 to n - m + 1 do + Parameters^[e + i] := NewString (AdditionalParameters[i + m - 1]^); + { Then the options from command-line } + i := e + n - m + 1; p := Compilers[PascalFlag].Options[OptionSelection]; while p <> nil do begin @@ -659,9 +664,7 @@ Parameters^[i] := @p^.Option; p := p^.Next end; - Assert (i = e + OptionCount); - for i := 1 to n - m + 1 do - Parameters^[e + OptionCount + i] := NewString (AdditionalParameters[i + m - 1]^); + Assert (i = e + OptionCount + n - m + 1); if (Verbosity >= 1) or (@CmdLine <> nil) then begin l := Length (Compilers[PascalFlag].ProgName); @@ -679,7 +682,7 @@ Pipe (Null, OutputFile, StdErrFile, Compilers[PascalFlag].ProgName, Parameters^, GetCEnvironment, Process, nil); Status := 0; Process^.Status := @Status; - for i := e + OptionCount + 1 to Parameters^.Count do + for i := e + 1 to e + n - m + 1 do Dispose (Parameters^[i]); Dispose (Parameters); if (@OutputFile = nil) and (@StdErrFile = nil) then Discard (WaitPipeProcess (Process))
Regards
Pascal Viandier pascal@accovia.com
<snip>
I am working on that to give you a clear example of what happens. I made a simple test program using a module that contains the {$L } directive and gp worked perfectly, even recompiling the c source when necessary. But with the real life application it fails repeatedly. I am trying to find the pattern and will let you know.
I found what is going on: I specify --object-destination-path=obj/dbg to gp. This option - as mentioned in a previous post - is not passed to gpc but I found that it is passed gcc so the gpc objects are in the gpi directory and the ones from gcc in obj/dbg. So the C objects are correctly compiled but not retrieved by gpc unless I put --object-path=obj/dbg option to gp.
I think this is a consequence of the fact that gp ignores the --object-destination-path option when it calls gpc. I will try to solve this one, if you agree.
Regards
Pascal Viandier pascal@accovia.com
Pascal Viandier wrote:
<snip> > > I am working on that to give you a clear example of what happens. I > made a > simple test program using a module that contains the {$L } directive > and > gp > worked perfectly, even recompiling the c source when necessary. But > with > the > real life application it fails repeatedly. I am trying to find the > pattern > and will let you know. >
I found what is going on: I specify --object-destination-path=obj/dbg to gp. This option - as mentioned in a previous post - is not passed to gpc but I found that it is passed gcc so the gpc objects are in the gpi directory and the ones from gcc in obj/dbg. So the C objects are correctly compiled but not retrieved by gpc unless I put --object-path=obj/dbg option to gp.
I think this is a consequence of the fact that gp ignores the --object-destination-path option when it calls gpc. I will try to solve this one, if you agree.
But the gpc manual says:
--unit-destination-path Path where to create object and GPI files of Pascal units. --no-unit-destination-path Create object and GPI files of Pascal units in the current directory (default). --object-destination-path Path where to create additional object files (e.g. of C files, not Pascal units). --no-object-destination-path Create additional object files (e.g. of C files, not Pascal units) in the current directory (default).
Regards,
Adriaan van Os
I agree with you Mr van Os: gp works "as documented".
My point is about why, when calling gpc directly, I can have gpi and object files in different directories but not when using gp.
Previously I was using make and gpc with a directory structure where gpi files were in a "gpi" directory and all objects from Pascal, C ,C++, and other languages where in a "obj" directory. If it is not possible to keep this directory structure, I will change it. That is no big deal.
However, I find a bit strange that gp can generate objects in two different directories depending on the source type and then not being able to retrieve them later without adding a command-line option (--object-path). Or maybe this was designed for a different purpose than mine.
Anyway after some tries, I don't see an easy way to change the actual behaviour, even for test purpose.
Regards,
Pascal Viandier pascal@accovia.com
-----Message d'origine----- De : gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] De la part de Adriaan van Os Envoyé : November 30, 2005 15:47 À : gpc@gnu.de Objet : Re: RE : gp vs --automake
Pascal Viandier wrote:
<snip> > > I am working on that to give you a clear example of what happens. I > made a > simple test program using a module that contains the {$L } directive > and > gp > worked perfectly, even recompiling the c source when necessary. But > with > the > real life application it fails repeatedly. I am trying to find the > pattern > and will let you know. >
I found what is going on: I specify --object-destination-path=obj/dbg to gp. This option - as mentioned in a previous post - is not passed to gpc but I found that it is passed gcc so the gpc objects are in the gpi directory and the ones from gcc in obj/dbg. So the C objects are correctly compiled but not retrieved by gpc unless I put --object-path=obj/dbg option to gp.
I think this is a consequence of the fact that gp ignores the --object-destination-path option when it calls gpc. I will try to solve this one, if you agree.
But the gpc manual says:
--unit-destination-path Path where to create object and GPI files of Pascal units. --no-unit-destination-path Create object and GPI files of Pascal units in the current directory (default). --object-destination-path Path where to create additional object files (e.g. of C files, not Pascal units). --no-object-destination-path Create additional object files (e.g. of C files, not Pascal units) in the current directory (default).
Regards,
Adriaan van Os
-
Adriaan van Os -
Frank Heckenbach -
Pascal Viandier