Hi,

Why is a runtime package (manual compilation only) forced to re-compile by a design time dependant package when the dependant package is compiled?

Stephano

Hi, Why is a runtime package (manual compilation only) forced to re-compile by a design time dependant package when the dependant package is compiled?

A "manual compilation only" is never recompiled automatically, unless you spotted a bug.
You can see why a package will be recompiled in View / IDE Internals/ What needs building.

Mattias

In what needs building (with the design package selected), the runtime package is marked as No build needed. Nevertheless, compiling the design time package tries to compile the runtime units.

Stephano

It turned out that the design time package had a other units path that included one unit of the runtime package. I know this is a bad practice, but does it fully explain the observed behaviour?

Thanks,
Stephano

I realise now why they shared the same path, but I am not sure if this is right or wrong. The registration unit of the design time package is in the same folder with the runtime units. Should it be placed in a separate folder?

Stephano

Yes.
Packages should not share sources (.pas files). Otherwise the compiler will happily recompile them.
If you must share sources, you should add -Ur.

Mattias

1- So sharing Other Units (-Fu) path causes units to recompile. Is there any other cause that can trigger an unnecessary recompilation?

2- On the other hand, What Needs Building/Lazarus IDE shows that the IDE does not need rebuilding (I changed the IDE build profile): Target: Lazarus IDE
No build needed. <------- ?????
File: ../lazarus-svn/

despite that the FCL needs it:
Target: FCL 1.0.1
Clean build needed. <------- ??????
File: /home/me/Programs/lazarus/lazarus-svn/packager/registration/fcl.lpk Note: Compiler parameters changed:
Old=""
Now=""
State
file="/home/me/Programs/lazarus/lazarus-svn/packager/units/i386-linux/FCL.compiled"

3- As shown above, FCL's Old and New compiler parameters are empty despite the change in the IDE profile. Should that be the case?

Thanks,
Stephano

[...] 1- So sharing Other Units (-Fu) path causes units to recompile. Is there any other cause that can trigger an unnecessary recompilation?

Yes, a bug in the compiler and if the unit does not use a given flag.

The IDE is a special case, because it is only built manually. So I didn't implement the test. That's why it is called "IDE internals". It's not for user friendliness.

No. What is difference between those two build profiles?

Mattias

Debug IDE: -gw -gl -godwarfsets -gh -gt -Co -Cr -Ci -Sa Optimized IDE: -O2 -g- -Xs

While switching IDE build profiles just now, I noticed the following: Target: ibo5xdt_laz 5.2.0.1
Build needed.
File:
/home/me/Documents/Data/Lazarus/IBO2LazarusConversion/ibo/packages/lazarus/ibo5xdt_laz.lpk Note: State file of FCL 1.0.1 is newer than state file of Package: ibo5xdt_laz 5.2.0.1
FCL 1.0.1=14/04/13 9:44:39 AM
Package: ibo5xdt_laz 5.2.0.1=14/04/13 9:31:03 AM

The package should not be recompiled under such circumstances, yet it marked as needs rebuilding!?

Stephano

Fixed.

Mattias

Thanks!

On the other hand, rebuilding the IDE seems to compile most if not all installed packages:

- Change the IDE build option (debug to optimized or vice-versa) and save the settings (do not build!)

- What Needs Building shows mainly: FCL, LCL, LCLBase, CodeTools, Cody, SynEdit, LazUtils, LazControls, lhelpcontrolpkg, IDEIntf, and SynEditDsgn.

- Build the IDE.

- Instead, many packages get compiled, such as: cairocanvas_pkg, ImagesForLazarus, lhelpcontrolpkg, Printer4Lazarus, ChmHelpPkg, customdrawn, ExternHelp, fpcunitide, lazreport, lazthread, printers4lazide, RunTimeTypeInfoControls, etc...

Stephano

Yes. If a required package was recompiled then all dependent packages need to be recompiled too.

Yes, because the above are directly effected by your changes. The purpose of this dialog is to find the cause of unneeded compilations. So I have not implemented the indirect tests. It's an IDE internal.

These packages need recompilation because one of the above packages was recompiled.

Mattias

Any chance of it appearing on your todo list? :)
It could help diagnosing package issues.

Clear enough!

Thanks,
Stephano

What issues?

Mattias

It is always good to know the exact reason why a package (or a unit/units belonging to a package) was or was not compiled. This relates mostly to user packages sharing the same folder thus forcing unnecessary units recompilation, include files not listed explicitly in packages and thus not causing automatic recompilation, etc...

Stephano

The dialog only shows what *will* be compiled, not why it *was* compiled.
You can see in the stdout log, why something was compiled.

This relates mostly to user packages sharing the same folder thus forcing unnecessary units recompilation, include files not listed explicitly in packages and thus not causing automatic recompilation, etc...

What has this to do with inherited compilation needs? Maybe you want a best practices analyzer for projects/packages?

Mattias

First, just to be clear, I am not pushing for the feature by replying.

A few days ago, I was experimenting with 'Manual compile only' packages and was puzzled why units pertaining to such a package were being recompiled when the IDE was rebuilt. You advised me to check IDE internals. Hence, the cycle was to inspect IDE internals, rebuild the IDE, and check the messages window. So I had an insight on what was supposed to be recompiled and most importantly why, and compared that with the actual compilation.

You can see in the stdout log, why something was compiled.

I believe the terminal (from which I launch startlazarus) is incapable of buffering so many lines. Are you referring to that terminal log, or to piping the output to a log file?

Not to that extent, but I find the IDE internals to be a good learning aid, and gives a good insight on the internals under the hood. It helps as well in debugging issues which might stem from bad practices, misunderstanding of the package mechanism, or plain bugs.

Stephano

Well, actually you are. And that's ok.

A few days ago, I was experimenting with 'Manual compile only' packages and was puzzled why units pertaining to such a package were being recompiled when the IDE was rebuilt. You advised me to check IDE internals.

Yes, it was more a reflex than a well thought answer. Manually compiled packages do not follow the recommendations. So I guess it will be hard to write an analyzer that gives the right advice.
For packages that share source directories the advice is easy, but maybe not pleasant.

You can pass --debug-log=log.txt as parameter.
Or use a better terminal. ;)

Yes, and when such dialog matures enough it becomes a normal dialog. Like the "Package links".

Mattias

I would suggest checking the package and perhaps projects as well against bad practices, and warn accordingly. the below is an initial list that I could think of:
- If the package is marked as anything other than 'rebuild automatically'
- If the package or project share the same folder as a required package
- If the package uses units or include files that are not included explicitly in the package. This is because any change to such code should trigger the need for recompilation. Unlisted code files are not checked as far as I understand.

I have that already as an option in my Lazarus launch script, but it requires a re-launch of the IDE. I use it for extreme cases.

Or use a better terminal. ;)

I use the Ubuntu default Gnome Terminal, and have just discovered (now) that its history capacity is configurable! Anyway, what terminal flavour do you recommend?

Exactly.

Stephano

Yes.

Gnome Terminal is ok. The default should be enough to see the last few thousand lines.

Mattias

Mine was set at 512 lines (I have been upgrading Ubuntu versions since 8.04 or 8.10). I'll make it unlimited.

Stephano

On 19/04/13 22:31, Mattias Gaertner wrote: [...] Mine was set at 512 lines (I have been upgrading Ubuntu versions since 8.04 or 8.10). I'll make it unlimited.

Then you can easily run out of memory.
Try 10 to 100.000 lines.

Mattias

Hadn't thought of that! I'll set it then to 10,000 for a start.

Stephano