Hello.
Does IDE clean all packages it depends on when rebuilding it from within the IDE with Clean All + Build?
What is the difference between "Clean + Build" and "Clean All + Build"?
cobines
Mailing lists / lazarus / 2011-10
Build Lazarus with Clean all - cleaning packages
14 messages · 4 people · –
- cobines 6
- Mattias Gaertner 4
- zeljko 3
- Juha Manninen 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
cobines wrote 6 lines
Hello.
Does IDE clean all packages it depends on when rebuilding it from
within the IDE with Clean All + Build?
What is the difference between "Clean + Build" and "Clean All + Build"?
It seem not. When rebuilded lazarus 33148 today , it refuses to link because some of .o files in 3rd party packages have linked old function from TControl (which is renamed today), so must cd into mypackage/source/lib/i386-linux/ and delete all o and ppu files, then lazarus builded ok.
zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111029/9f0cbe23/attachment.html>
Hello. Does IDE clean all packages it depends on when rebuilding it from within the IDE…
Hello. Does IDE clean all packages it depends on when rebuilding it from within the IDE with Clean All + Build?
No.
This is needed.
What is the difference between "Clean + Build" and "Clean All + Build"?
clean + build:
make -C cleanide ide
It deletes the files in the output directory of the IDE.
clean all + build:
make clean ide
As above but also deletes the files in the output
directory of all parts that are required to build a minimum IDE and lazbuild. LCL, LCLBase, codetools, lazcontrols, ideintf, lazutils, registration package "FCL".
Mattias
It seem not. When rebuilded lazarus 33148 today , it refuses to link because some of .o…
2011/10/29 zeljko :
Show quoted text 5 lines
It seem not. When rebuilded lazarus 33148 today , it refuses to link because
some of .o files in 3rd party packages have linked old function from
TControl (which is renamed today), so must cd into
mypackage/source/lib/i386-linux/ and delete all o and ppu files, then
lazarus builded ok.
Yes, I asked because of exactly the same problem. Cleaning with "make clean", "make bigideclean", etc. didn't help but deleting all *.o *.ppu manually did.
cobines
On Sat, 29 Oct 2011 17:21:42 +0200 No. This is needed. clean + build: make -C cleanide ide
2011/10/29 Mattias Gaertner :
Show quoted text 10 lines
On Sat, 29 Oct 2011 17:21:42 +0200
cobines wrote:
> Hello.
>
> Does IDE clean all packages it depends on when rebuilding it from
> within the IDE with Clean All + Build?
No.
This is needed.
OK. I even found a bug report on this already.
http://bugs.freepascal.org/view.php?id=14079
Show quoted text 12 lines
> What is the difference between "Clean + Build" and "Clean All + Build"?
clean + build:
make -C cleanide ide
It deletes the files in the output directory of the IDE.
clean all + build:
make clean ide
As above but also deletes the files in the output
directory of all parts that are required to build a minimum IDE and
lazbuild. LCL, LCLBase, codetools, lazcontrols, ideintf, lazutils,
registration package "FCL".
I see, thanks. The Clean All is sometimes not enough, but if cleaning packages would be implemented I guess it could replace it.
cobines
2011/10/29 cobines
2011/10/29 Mattias Gaertner : > clean all + build: > make clean ide
In fact it is "make cleanlaz ide".
Maybe it does the same thing as "make clean ide", I didn't check that.
I see, thanks. The Clean All is sometimes not enough, but if cleaning
packages would be implemented I guess it could replace it.
Yes but I think the current makefile does not support it. (?) Fixing it needs more than just changing make params.
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111029/b4a040d0/attachment.html>
Juha Manninen wroteYes but I think the current makefile does not support it. (?) Fixing it needs more than just changing make params.
Can it pass somehow to 3rd party packages "recompile clean" cmd or similar. ?
z.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111029/2be3e62d/attachment.html>
2011/10/29 Mattias Gaertner : OK. I even found a bug report on this already.…
Shouldn't the package files be rebuilt automatically? For example package "A" depends on LCL. The LCL source files change and LCL package is rebuilt manually or automatically (*.o, *.ppu change). Then you rebuild package "A" and the files that use the changed files should be rebuilt. But they are not and it is required to delete them first.
Or it doesn't work like that?
cobines
Shouldn't the package files be rebuilt automatically?
Yes. They are. The IDE even add the -B option if needed. But there are some corner cases.
Show quoted text 8 lines
For example
package "A" depends on LCL. The LCL source files change and LCL
package is rebuilt manually or automatically (*.o, *.ppu change). Then
you rebuild package "A" and the files that use the changed files
should be rebuilt. But they are not and it is required to delete them
first.
Or it doesn't work like that?
It does work in normal cases.
But when you switch from one Lazarus version to another or when people mess up things, the automatic detection of the IDE and/or FPC may fail and manual clean up is needed.
That's why 0.9.31 has a "Run / clean up build files". Something similar is needed for the IDE and lazbuild. I will implement it next week.
Mattias
2011/10/29 Mattias Gaertner :
Show quoted text 8 lines
On Sat, 29 Oct 2011 21:09:50 +0200
cobines wrote:
> Shouldn't the package files be rebuilt automatically?
Yes. They are. The IDE even add the -B option if needed.
But there are some corner cases.
....
It does work in normal cases.
When package is built even manually, from the IDE or using lazbuild not all files are rebuilt. I think it is FPC issue because it doesn't always work with 2.4.4 but it does with 2.5.1 and 2.7.1.
I'll put things into example.
I have virtualtreeview installed. In the package there is VTHeaderPopup that uses VirtualTrees and VirtualTrees that uses Controls (from LCL). I introduce a new function:
function TControl.AutoSizeSomething: Boolean; virtual;
begin
Result := True;
end;I change TControl.AutoSizeDelayedHandle:
begin
- Result := (Parent = nil);
+ Result := (Parent = nil) and AutoSizeSomething;
end;so that the function is used somewhere.
I clean virtualtreeview manually, open the .lpk press compile. The VTHeaderPopup.o contains ...AUTOSIZESOMETHING symbol.
I rename AutoSizeSomething -> AutoSizeNothing.
I open the virtualtreeview.lpk and press Compile. It rebuilds LCLBase, LCL and virtualtreeview. The VirtualTrees unit is rebuilt and now contains AUTOSIZENOTHING but the VTHeaderPopup unit is not rebuilt, it still contains AUTOSIZESOMETHING, so linking IDE would fail because cannot find the symbol. If from the package editor I choose "More/Recompile all required" then VTHeaderPopup is rebuilt (maybe adds -B?).
But like I said the problem seems to be gone starting with FPC 2.5.1, so as long as files are added to .lpk they should be rebuilt. The reason for cleaning might be when source files are not in .lpk or have been deleted but the *.ppu and *.o still exist.
cobines
Show quoted text 15 lines
2011/10/29 Mattias Gaertner :
> On Sat, 29 Oct 2011 21:09:50 +0200
> cobines wrote:
>
>> Shouldn't the package files be rebuilt automatically?
>
> Yes. They are. The IDE even add the -B option if needed.
> But there are some corner cases.
>
....
>
> It does work in normal cases.
When package is built even manually, from the IDE or using lazbuild
not all files are rebuilt.
Yes, and there are cases where rebuilding is not enough. For example when a file was moved one package up, then you must delete ppu files. Because fpc never does that, rebuilding is not always sufficient, even with -B.
Show quoted text 33 lines
I think it is FPC issue because it doesn't
always work with 2.4.4 but it does with 2.5.1 and 2.7.1.
I'll put things into example.
I have virtualtreeview installed. In the package there is
VTHeaderPopup that uses VirtualTrees and VirtualTrees that uses
Controls (from LCL). I introduce a new function:
function TControl.AutoSizeSomething: Boolean; virtual;
begin
Result := True;
end;
I change TControl.AutoSizeDelayedHandle:
begin
- Result := (Parent = nil);
+ Result := (Parent = nil) and AutoSizeSomething;
end;
so that the function is used somewhere.
I clean virtualtreeview manually, open the .lpk press compile. The
VTHeaderPopup.o contains ...AUTOSIZESOMETHING symbol.
I rename AutoSizeSomething -> AutoSizeNothing.
I open the virtualtreeview.lpk and press Compile. It rebuilds LCLBase,
LCL and virtualtreeview. The VirtualTrees unit is rebuilt and now
contains AUTOSIZENOTHING but the VTHeaderPopup unit is not rebuilt, it
still contains AUTOSIZESOMETHING, so linking IDE would fail because
cannot find the symbol.
Yes, that is a fpc bug. A few such cases were fixed in fpc, but afaik there are still a few cases.
Of course the IDE can not detect such a thing neither, unless it reimplements a whole ppu check like the compiler. Makes no sense.
If from the package editor I choose "More/Recompile all required" then VTHeaderPopup is rebuilt (maybe adds -B?).
Yes.
But like I said the problem seems to be gone starting with FPC 2.5.1, so as long as files are added to .lpk they should be rebuilt. The reason for cleaning might be when source files are not in .lpk or have been deleted but the *.ppu and *.o still exist.
Afaik this is only the symptom. The real problem is the algorithm checking the dependency of the checksums in ppu files.
Mattias
2011/10/29 zeljko : Yes, I asked because of exactly the same problem. Cleaning with "make…
Show quoted text 10 lines
2011/10/29 zeljko :
> It seem not. When rebuilded lazarus 33148 today , it refuses to link because
> some of .o files in 3rd party packages have linked old function from
> TControl (which is renamed today), so must cd into
> mypackage/source/lib/i386-linux/ and delete all o and ppu files, then
> lazarus builded ok.
Yes, I asked because of exactly the same problem. Cleaning with "make
clean", "make bigideclean", etc. didn't help but deleting all *.o
*.ppu manually did.
The IDE now deletes all files in the unit output directory of a package when the package is compiled clean.
It checks if the directory is shared with a required package.
This means: if you have two unrelated packages which share the unit output directory, you have to change one of the output directories or set one of them to compile manually.
Mattias
Mattias Gaertner wrote 22 lines
On Sat, 29 Oct 2011 20:12:24 +0200
cobines wrote:
> 2011/10/29 zeljko :
> > It seem not. When rebuilded lazarus 33148 today , it refuses to link
> > because some of .o files in 3rd party packages have linked old
> > function from TControl (which is renamed today), so must cd into
> > mypackage/source/lib/i386-linux/ and delete all o and ppu files, then
> > lazarus builded ok.
>
> Yes, I asked because of exactly the same problem. Cleaning with "make
> clean", "make bigideclean", etc. didn't help but deleting all *.o
> *.ppu manually did.
The IDE now deletes all files in the unit output directory of a package
when the package is compiled clean.
It checks if the directory is shared with a required package.
This means: if you have two unrelated packages which share the unit
output directory, you have to change one of the output directories or
set one of them to compile manually.
Yes that works fine now.
Thanks.
zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111101/ee7fdde5/attachment.html>
On Sat, 29 Oct 2011 20:12:24 +0200 The IDE now deletes all files in the unit output…
2011/11/1 Mattias Gaertner :
The IDE now deletes all files in the unit output directory of a package when the package is compiled clean.
Thanks.
cobines