I also tried distclean cleanall cleanbigide

There are compiled units all over the place in lib/* folders left over after clean, a fresh download compresses into 46MB tarball, after first successful build I cannot get it smaller than 65MB. How do I *really* clean the source directory? Is there yet another makefile target for this purpose or do I have to write a script and recursively find and delete all these files myself?

What files are not deleted?

Mattias

I had related problems with FPC apparently due to fpmake not cleaning everything.
See message thread titled
FPC x86+x64 win trunk failing to build (using fpcup): 2 different errors from September 20

I modified my fpcup program to recursively delete all .ppu, .a, .o files in any directory with the right "cpu-os signature" (my term) (i386-linux...etc).

Some of these .a and/or .o are provided by svn so I did an svn update after that.

Don't know if this also applies to Lazarus...
In any case, for Lazarus fpcup employs the same strategy but also deletes .or and .res files in the "cpu-os signature" directories

Regards,
Reinier

No, it does not. L does not use fpmake and it does not have .o, .ppu, .a files in svn.
The Makefiles use globbing to delete, for example *.ppu.

In any case, for Lazarus fpcup employs the same strategy but also deletes .or and .res files in the "cpu-os signature" directories

Mattias

Bernd wrote

first successful build I cannot get it smaller than 65MB. How do I *really* clean the source directory?

I've seen this issue mentioned here before. From memory some use the 'svn export' command to get a really clean directory layout.

If you are using the Git mirror, you can simply do 'git clean' which will really clean out anything that is not part of the repository. The 'git clean' command has various parameters to adjust exactly how fine grained you want the clean process to be. You can also use 'git archive'
- very nice for creating release source code archives.

Regards,
- Graeme -

find . -name "*.ppu" -exec rm -f {} \;
same for *.o

z.

zeljko wrote

find . -name "*.ppu" -exec rm -f {} \; same for *.o

and *.a and ppas.sh and executables and left over empty directories etc.

So no, 'find ...' is definitely not the best, and most reliable, method of getting a clean directory layout.

Graeme.

Graeme Geldenhuys hat am 8. Oktober 2012 um 10:56 geschrieben:

ppas.sh are deleted by fpc.
.a are not created.
Empty directories must be kept.

So no, 'find ...' is definitely not the best, and most reliable, method of getting a clean directory layout.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121008/c89ba33b/attachment.html>

Mattias Gaertner wrote

ppas.sh are deleted by fpc.

I often have ppas.sh files in my source folders. So somewhere clean-up is not working 100%

.a are not created.

I often have these files lying around in my unit output directories too.

I just checked, and just about every project I work on has *.a, *.o, *.ppu, *.compiled, *.lps, *.rst, the executables for various target platforms, unit/*/ unit output directories, and sometimes *.bak files. All files and directories that are not part of the repository managed files. Then sometimes when I do deep debugging I have ASM output files too.

My point is, a simple 'find ...' command will not clean out all non-repository files. You need something a bit more intelligent like 'git clean'.

Regards,
- Graeme -

Something like this:
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn-cle an

Ludo

2012/10/8 Graeme Geldenhuys :

My point is, a simple 'find ...' command will not clean out all non-repository files. You need something a bit more intelligent like 'git clean'.

git-clean is also only a workaround, its just using the information it knows about which files are version controlled and which are not (and I can only use it on my local machine, not inside a build script on sources that are uploaded to launchpad). Ideally the clean target of each makefile in each directory should exactly know which files (and which folders) could have been created and rm -rf them.

I'm going to make a diff to see what exactly is left behind (which makefiles are broken) but not today (and also not tomorrow). Until then I think I use the recursive find method as a quick & dirty hack just to get the sheer file size down before uploading to launchpad (Currently I'm mostly worried about file size because I have slow ADSL, not so much about empty directories).

2012/10/8 Mattias Gaertner :

.a are not created.

afaik .a result from compiling with -CX.

Graeme Geldenhuys hat am 8. Oktober 2012 um 12:16 geschrieben:

Then you should create a bug report.

> .a are not created. I often have these files lying around in my unit output directories too.

This thread is about Lazarus sources.

I just checked, and just about every project I work on has *.a, *.o, *.ppu, *.compiled, *.lps, *.rst, the executables for various target platforms, unit/*/ unit output directories, and sometimes *.bak files.

.bak are created by the IDE as backups of sources. "make clean" should not delete source files, nor backups.
.lps should not be be deleted by make clean.
.ppu, .o, .rst and .compiled should be deleted by "make clean". .a are not created in Lazarus sources.

We had this discussion already. "make clean" is *not* meant as revert and reset. It must *not* delete everything.
I don't see how this helps Bernd.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121008/4760d97d/attachment.html>

Bernd wrote

git-clean is also only a workaround, its just using the information it

Hardly a work-around. It's a standard git command that's been around for ages. git-clean queries the [local] repository to know exactly what files are version controlled. It then also and
.git/info/exclude files to see what was your preference of ignored files. It can also look at the parameters you gave it, for even more control, and what to do about unversioned directories.

sources that are uploaded to launchpad). Ideally the clean target of each makefile in each directory should exactly know which files (and which folders) could have been created and rm -rf them.

Makefiles are pretty terrible. If you get an update before you did a 'make clean', then the update could have deleted source code units, remove makefiles etc. So afterwards your Makefiles are inconsistent with what you had before. So 'make clean' will not know about earlier files and directories. This is a common problem often raised here in this mailing list.

I think your quickest, and cleanest solution is to simply do a 'svn export', then archive that exported directory for upload to launchpad. Or use 'git archive' (no need for git-clean) if you are using the git mirrors.

Regards,
- Graeme -

Graeme Geldenhuys hat am 8. Oktober 2012 um 13:24 geschrieben:

[...] I think your quickest, and cleanest solution is to simply do a 'svn export', then archive that exported directory for upload to launchpad.

No. Bernd, please help us to fix the bug.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121008/cc129e5f/attachment.html>

That's very possible in Lazarus sources too. There are projects in the <laz>/tools/ directory (eg: lazdatadesktop) etc that often needs debugging to. So adjusting the default compiler options in normal, and could result in extra files in unit output directories. The same can be said about the lcl.lpk package.

Well, if you are going to make an archive (.zip, .tar.gz etc) of the lazarus checked-out repository, for some distribution or build server, you definitely don't want those files or output directories in such archives. I thought that is what Bernd was trying to do.

Graeme.

2012/10/8 Mattias Gaertner :

No. Bernd, please help us to fix the bug.

Yes, this is my intention. I also have one or two complaints about make install as it is currently (it will fail with error when run by dh_auto_install because of recursive copy into itself, thats why I am now forced to not use it at all and instead copy all stuff manually, I will file a bug for this too.

Graeme Geldenhuys hat am 8. Oktober 2012 um 13:49 geschrieben:

If that is his goal, then yes, you must use svn export.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121008/0e1eb76e/attachment.html>

You are wrong regarding ".a" files. They are at least created for the Windows widgetsets. Here the files that I have:

lazarus/lcl/units/i386-win32/win32/libimpwin32wsforms.a lazarus/lcl/units/arm-wince/wince/libimpwincedef.a lazarus/lcl/units/arm-wince/wince/libimpwinceextra.a

And what about *.res files?

Regards,
Sven

No. They are necessary for DLL imports at least on the Windows platforms.

Regards,
Sven

Sven Barth hat am 8. Oktober 2012 um 14:03
geschrieben:

It seems to me Bernd meant Linux.
Of course you can pass options to 'make' to create all kind of unusual files. But there is no 'make' command to delete-all-except, so it is impossible to fix all cases.
We can add *.a to those places where it is missing, but that won't fix Bernd's issue about ppu files.

And what about *.res files?

They are not created/updated by make.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121008/6df39e79/attachment-0001.html>

2012/10/8 Mattias Gaertner :

.a are not created.

here are 1082 .a files left over after cleanbigide cleanall clean distclean: http://pastebin.com/dY1ih1K0

and 44 .res files:
http://pastebin.com/dyUFMRdM

I could not find any .ppu or .o but after removing all these a files compressed size is reasonable 46MB again. Ideally make clean would rm -rf all these i386-linux folders entirely, the makefile should know the folder name for the current architecture and os.

2012/10/8 Sven Barth :

> afaik .a result from compiling with -CX. No. They are necessary for DLL imports at least on the Windows platforms.

citing the manual: http://www.freepascal.org/docs-html/prog/progse29.html

"When a unit foo.pp is smartlinked, the name of the codefile is changed to libfoo.a.

Technically speaking, the compiler makes small assembler files for each procedure and function in the unit, as well as for all global defined variables (whether they?re in the interface section or not). It then assembles all these small files, and uses ar to collect the resulting object files in one archive. "

Seems like the documentation regarding this isn't that up to date anymore...

You just need to test yourself: create a unit with a bit of code and compile using "-CX". At least on my system I haven't found a "libUNITNAME.a" file. What I did find though when I add an import ("external '...'") was a libimpUNITNAME.a file. It could be different on a Linux system of course, but at least on Windows systems the compiler works this way.

Nevertheless: *.a files are created by the compiler and need to be cleaned away as well.

Regards,
Sven

Feel free to create a feature request.

Mattias

2012/10/8 Sven Barth :

You just need to test yourself: create a unit with a bit of code and compile using "-CX". At least on my system I haven't found a "libUNITNAME.a" file.

--(bernd at t40)-(/home/bernd/Desktop/smartlinktest)-- --($)-- ls
insgesamt 20
drwxr-xr-x 2 bernd bernd 4096 Okt 9 01:44 .
drwx------ 12 bernd bernd 4096 Okt 9 01:37 ..
-rw-r--r-- 1 bernd bernd 48 Okt 9 01:39 prog.pas -rw-r--r-- 1 bernd bernd 51 Okt 9 01:41 unita.pas -rw-r--r-- 1 bernd bernd 51 Okt 9 01:41 unitb.pas

--(bernd at t40)-(/home/bernd/Desktop/smartlinktest)--

--($)-- cat prog.pas
program prog;

uses
unita,

	unitb;

begin
end.

--(bernd at t40)-(/home/bernd/Desktop/smartlinktest)-- --($)-- cat unita.pas
unit unita;

interface
implementation
begin
end.

--(bernd at t40)-(/home/bernd/Desktop/smartlinktest)-- --($)-- cat unitb.pas
unit unitb;

interface
implementation
begin
end.

--(bernd at t40)-(/home/bernd/Desktop/smartlinktest)-- --($)-- fpc -CX -XX prog.pas
Free Pascal Compiler version 2.6.0 [2012/10/07] for i386 Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Linux for i386
Compiling prog.pas
Compiling unita.pas
Compiling unitb.pas
Linking prog
/usr/bin/ld: warning: link.res contains output sections; did you forget -T? 24 lines compiled, 1.5 sec

--(bernd at t40)-(/home/bernd/Desktop/smartlinktest)-- --($)-- ls
insgesamt 104
drwxr-xr-x 2 bernd bernd 4096 Okt 9 01:46 .
drwx------ 12 bernd bernd 4096 Okt 9 01:37 ..
-rw-r--r-- 1 bernd bernd 16026 Okt 9 01:46 libpprog.a -rw-r--r-- 1 bernd bernd 8988 Okt 9 01:46 libpunita.a -rw-r--r-- 1 bernd bernd 8988 Okt 9 01:46 libpunitb.a -rwxr-xr-x 1 bernd bernd 21980 Okt 9 01:46 prog
-rw-r--r-- 1 bernd bernd 1696 Okt 9 01:46 prog.o -rw-r--r-- 1 bernd bernd 48 Okt 9 01:39 prog.pas -rw-r--r-- 1 bernd bernd 791 Okt 9 01:46 unita.o -rw-r--r-- 1 bernd bernd 51 Okt 9 01:41 unita.pas -rw-r--r-- 1 bernd bernd 624 Okt 9 01:46 unita.ppu -rw-r--r-- 1 bernd bernd 791 Okt 9 01:46 unitb.o -rw-r--r-- 1 bernd bernd 51 Okt 9 01:41 unitb.pas -rw-r--r-- 1 bernd bernd 624 Okt 9 01:46 unitb.ppu

Bernd wrote

2012/10/8 Sven Barth : > You just need to test yourself: create a unit with a bit of code and compile > using "-CX". At least on my system I haven't found a "libUNITNAME.a" file.

[snip]

Than this seems to apply only to non-Windows platforms indeed... (or maybe only if the external linker is used).

Regards,
Sven

2012/10/9 Sven Barth :

Than this seems to apply only to non-Windows platforms indeed... (or maybe only if the external linker is used).

Yes. Probably ld simply needs it this way while the internal linker can more or less implement it like it wants.

FYI: FPC make distclean didn't work:

fpc trunk log:
r22621 | joost | 2012-10-12 23:26:16 +0200 (Friday, 12 Oct 2012) | 6 lines

* For some reason burried in the past a 'make distclean' in fpc's root is passed to utils as a 'make cleanall' which is an alias for 'distclean'.
The Makefile.fpc did not recognize the 'cleanall' alias because in packages 'distclean' is being used. This means that nothing was cleaned at all.

fppkg is compiled by fpmake by default.

Joost.