Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2000-04

Copmpiler dependency bug ??

7 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Marc Weustink
to Marc Weustink: I'm not talking about the creation order nor changingfiles nor using make. As you…
Michael Van Canneyt wrote 7 lines
Just another short note: Delphi recompiles units A,B and C the second time; --> so with FPC you win 1 compile :-) If you give Delphi the -M option (only make changed units) it recompiles ONLY unit a the second time, which is apparently the behaviour you expect.

This is what I expect since fpc seems to do the same (fpc has no -M like option)

In any case, it is always dangerous to have circular unit dependencies,

Why ?

And in my opinion you should re-think the unit structure in such case. But that is only my personal opinion.

Under certain circumstances you can't avoid it (exept if you do a complete rewrite or if you put both units in one unit :-)

In our case, the interfaces needs to know about controls, controls in their case interface with the interfaces.

The VCL uses this construction as well, from controls.pas:

   implementation
   uses Consts, Forms, ActiveX;

Marc

Reply by email

Michael Van Canneyt
to Marc Weustink: I'm not talking about the creation order nor changingfiles nor using make. As you…
Marc Weustink wrote
At 13:16 08-04-2000 -0400, Michael A. Hess wrote: >Marc Weustink wrote:

[cut]

Show quoted text 5 lines
What I try to make clear is as long as this "recompilation" is the case we can't create an "indepandent" LCL, IE, a LCL with only compiled units. For every project, the compiler wants to rebuild the LCL (and that's something we don't want).

I've forwarded this mail to Pierre Muller, he is the one who implemented the current CRC checking scheme.

I'll inform you of any news.

Michael.

Reply by email

Michael A. Hess
to Marc Weustink: While addapting the makefiles I ran into the following problem: In the interface unit A…
Marc Weustink wrote 11 lines
Hi, While addapting the makefiles I ran into the following problem: In the interface unit A uses B In the interface unit B uses C In the implementation unit C uses A When you compile A, unit B and C are created as well. If you compile A again unit B is recompiled, since the checksum for C is changed. This is IMO not correct, nothing is changed.

It shouldn't. If you compile A it used B so it depends on B being compiled FIRST. When B tries to compile before A it determines that C must be compile FIRST. So first C is compiled then this allows B to be compiled which then allows A to be compiled. The lowest on in the chain is always compiled first. If you make changes to unit A and try to recompile it it will note that neither B or C has changed since A was compiled last and will not recompile them.

Now that is at least HOW it should work. If you are seeing something different then there is a problem.

If you compile A then the make file should never ask B or C to compile since the date check will have determined that they were already compiled by A.

What leads you to believe that this isn't working? I'm not say it is or isn't or that your analysis isn't correct I just haven't seen this problem yet.

==== Programming my first best destiny! ==== Michael A. Hess Miracle Concepts, Inc. http://www.miraclec.com

Reply by email

Michael Van Canneyt
to Marc Weustink: I'm not talking about the creation order nor changingfiles nor using make. As you…
Marc Weustink wrote
What I try to make clear is as long as this "recompilation" is the case we can't create an "indepandent" LCL, IE, a LCL with only compiled units. For every project, the compiler wants to rebuild the LCL (and that's something we don't want).

Just another short note:

Delphi recompiles units A,B and C the second time;
--> so with FPC you win 1 compile :-)

If you give Delphi the -M option (only make changed units) it recompiles ONLY unit a the second time, which is apparently the behaviour you expect.

In any case, it is always dangerous to have circular unit dependencies, And in my opinion you should re-think the unit structure in such case. But that is only my personal opinion.

Michael.

Reply by email

Marc Weustink
to Marc Weustink: While addapting the makefiles I ran into the following problem: In the interface unit A…
Michael A. Hess wrote 31 lines
Marc Weustink wrote: > > Hi, > While addapting the makefiles I ran into the following problem: > > In the interface unit A uses B > In the interface unit B uses C > In the implementation unit C uses A > > When you compile A, unit B and C are created as well. If you compile A > again unit B is recompiled, since the checksum for C is changed. > This is IMO not correct, nothing is changed. It shouldn't. If you compile A it used B so it depends on B being compiled FIRST. When B tries to compile before A it determines that C must be compile FIRST. So first C is compiled then this allows B to be compiled which then allows A to be compiled. The lowest on in the chain is always compiled first. If you make changes to unit A and try to recompile it it will note that neither B or C has changed since A was compiled last and will not recompile them. Now that is at least HOW it should work. If you are seeing something different then there is a problem. If you compile A then the make file should never ask B or C to compile since the date check will have determined that they were already compiled by A. What leads you to believe that this isn't working? I'm not say it is or isn't or that your analysis isn't correct I just haven't seen this problem yet.

I'm not talking about the creation order nor changingfiles nor using make.

As you confirmed, if you compile A, C and B are compiled first. Correct. If you don't change anything and you recompile A, B and C are still there and it shouldn't be necesary to recompile them.

What I see is that unit B is recompiled the second time I compile A. After that only a is compiled.
Try the example I've attached.

marc:~/fpc/lazarus/examples/test$ ppc386 a
Target OS: Linux for i386
Compiling a.pas
Compiling b.pas
Compiling c.pas
Compiling a.pas
Compiling b.pas
Assembling (pipe) b.s
Assembling (pipe) a.s
Assembling (pipe) c.s
57 Lines compiled, 0.0 sec
marc:~/fpc/lazarus/examples/test$ ppc386 a
Target OS: Linux for i386
Compiling a.pas
Compiling b.pas
Assembling (pipe) b.s
21 Lines compiled, 0.0 sec
marc:~/fpc/lazarus/examples/test$ ppc386 a
Target OS: Linux for i386
Compiling a.pas
6 Lines compiled, 0.0 sec
marc:~/fpc/lazarus/examples/test$

What I try to make clear is as long as this "recompilation" is the case we can't create an "indepandent" LCL, IE, a LCL with only compiled units. For every project, the compiler wants to rebuild the LCL (and that's something we don't want).

Marc

Reply by email

Marc Weustink

Hi,
While addapting the makefiles I ran into the following problem:

In the interface unit A uses B
In the interface unit B uses C
In the implementation unit C uses A

When you compile A, unit B and C are created as well. If you compile A again unit B is recompiled, since the checksum for C is changed. This is IMO not correct, nothing is changed.

Marc

---------------------------------------------------------
unit A;
interface
uses
   b;
procedure AA;
implementation
procedure AA;
begin
end;
end.
---------------------------------------------------------
unit B;
interface
uses
   c;
procedure BB;
implementation
procedure BB;
begin
end;
end.
---------------------------------------------------------
unit C;
interface
procedure CC;
implementation
uses
   a;
procedure CC;
begin
end;
end.
---------------------------------------------------------

Reply by email

Michael A. Hess
to Marc Weustink
Marc Weustink wrote
I'm not talking about the creation order nor changingfiles nor using make.

I understood that.

What I see is that unit B is recompiled the second time I compile A. After that only a is compiled.

This is what I meant by asking what lead you to believe this. If this is what is happening then yes there is a problem. There is no reason that B should compile again. As MVC said he will forward it to the party that deals with this issue in the compiler. Good catch!

==== Programming my first best destiny! ==== Michael A. Hess Miracle Concepts, Inc. http://www.miraclec.com

Reply by email