Hi,

I update my Trunk version of Lazarus today. My update process normally includes the following:

1) Get the latest source code
2) do a "make bigide"
3) Run Lazarus IDE
4) Recompile Lazarus via the "Tools - Configure 'build lazarus'" This last step is so that my custom packages (eg: leaktest, editortoolbar etc) are installed.

Before today, my last update of Lazarus trunk was November 2011. Anyway, all went fine up to Step 3. In Step 4 I got an error from the customcontrols package that cannot be found. It seems to be a new default included package (I didn't select it myself), but Lazarus can't seem to find it. It also complained about a missing unit (see attached screenshot). To get around this problems I had to uninstall the package via "Packages - Install/Uninstall packages" menu. Then rebuild the IDE - which worked.

Anyway, I didn't know where this missing unit lives, and I don't know why Lazarus couldn't find it in the first place, considering that it seems to be a default selected/installed package of Lazarus.

I hope you did a "make bigideclean bidide".

AFAIK at that time Felipe started the customdrawn controls. Maybe there were some things wrong.

Anyway, all went fine up to Step 3. In Step 4 I got an error from the customcontrols package that cannot be found.

Is the name correct? Was it really "customcontrols"?

It seems to be a new default included package (I didn't select it myself), but Lazarus can't seem to find it. It also complained about a missing unit (see attached screenshot).

The screenshot shows: customdrawncontrols.pas
This unit is in the directory lcl belongs to lclbase.lpk. Before that it was in the customdrawn package.

Mattias

Try removing lcl/units and components/customdrawn/units and try again

2012/2/22 Graeme Geldenhuys :

Use 'make distclean' in Lazarus directory; update from SVN again (if you can); open the IDE and click 'Build and Clean all'; I never used make bigide, just the IDE and menu Build.

Marcos Douglas

Felipe Monteiro de Carvalho wrote

Try removing lcl/units and components/customdrawn/units and try again

OK, I thought I would try one at a time first - to more accurately pinpoint the exact cause.

I didn't have a components/customdrawn/units/ directory, but I did have a components/customdrawn/lib/ directory.

Removing that 'lib' directory, and then trying to rebuild the IDE via the 'Tools > Configure Build Lazarus' worked!

So that simply means there was outdated compiled units left behind. So why didn't 'make clean' as I originally ran it, or the 'make bigideclean' as Mattias suggested clean out this directory?

So the 'make clean<whatever>' doesn't actually do a very good job. :-(

Anyway, thanks for finding a solution to my problem. Now all that remains, is fixing the 'make clean...' issue.

AFAIK make clean only removes files it knows about. If the unit directory got renamed from lib to units then it dies not know there is a lib directory to clean (it could be a directory created by the user after all). I don't know whether this is your exact course, but it's at least the situation as I remember it.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120223/cc25d246/attachment.html>

Marcos Douglas wrote

Use 'make distclean' in Lazarus directory;

Oh God, yet another 'make clean' option!!! How many "clean" options does the Lazarus project have??

Anyway, I don't think it is going to make much of a difference now - seeing that I removed the outdated compiled units already.

But while you are here... What is the difference between all the "make clean..." options, and how many "clean" options do we really have? Does Lazarus really need them all? Can't we just have a single 'make clean' that really does the job as the name suggests?

Good news for those using the Git mirror repository. I just found out that git has a "really clean" option.

git clean -d -x -f

-d Delete untracked directories too
-x Do not use the git ignore file rules
-f Force a "yes to all" to remove all untracked files.

Here is that command in a "dry-run" mode:

----------------------------------------
[lazarus (graemeg)]$ git clean -d -x -f -n
Would remove lazarus
Would remove startlazarus
Would remove svndiff
Would remove components/cgi/
Would remove components/chmhelp/lhelp/lhelp.or
Would remove components/chmhelp/lhelp/ppas.sh
Would remove components/chmhelp/packages/help/lib/ Would remove components/chmhelp/packages/idehelp/lib/ Would remove components/customdrawn/lib/
Would remove components/datadict/lib/
Would remove components/dbexport/lib/
Would remove components/editortoolbar/languages/edttbconfigfrm.po Would remove components/editortoolbar/lib/
Would remove components/externhelp/lib/
Would remove components/filebrowser/lib/
Would remove components/fpcunit/console/lib/
Would remove components/instantfpc/lib/
Would remove components/leakview/lib/
Would remove components/printers/design/lib/
Would remove components/projecttemplates/lib/
Would remove components/sdf/lib/
Would remove components/tachart/lib/
Would remove components/tdbf/lib/
Would remove components/todolist/lib/
Would remove components/turbopower_ipro/design/lib/ Would remove debugger/fpdebug/fpd/fpd.ico
Would remove debugger/fpdebug/fpd/fpd.lpi
Would remove debugger/fpdebug/fpd/fpd.res
Would remove debugger/test/Gdbmi/TestApps/lib/
Would remove debugger/test/Gdbmi/TestGdbmi
Would remove debugger/test/Gdbmi/TestGdbmi.res
Would remove debugger/test/Gdbmi/lib/
Would remove docs/html/build_txt.sh
Would remove docs/html/lcl.inf
Would remove examples/dragimagelist/project1
Would remove examples/dragimagelist/project1.or
Would remove examples/dropfiles/dropfiles
Would remove examples/dropfiles/dropfiles.or
Would remove lcl/Controls_lcl.pas
Would remove lcl/interfaces/fpgui/corelib
Would remove lcl/interfaces/fpgui/fpgui_listing.txt Would remove lcl/interfaces/fpgui/gui
Would remove lcl/languages/fpg_constants.po
Would remove lcl/units/
Would remove lib/
Would remove testgit
Would remove testgit.lpi
Would remove testgit.lpr
Would remove tools/debugserver/debugserver
Would remove tools/debugserver/debugserver.exe
Would remove tools/debugserver/debugserver.or
Would remove tools/jsonviewer/go.sh
Would remove tools/jsonviewer/jsonviewer
Would remove tools/libpsvn2revisioninc.a
Would remove tools/revision.inc
Would remove tools/updatepofiles
....[snip]...
----------------------------------------

After this I searched the lazarus directory structure. There are NO executables, compiled units or other temp files lying around. The lazarus directory is now in a pristine state. I guess I'll use the 'git clean' command from now onwards.

Maybe if the makefile "clean" is not sufficient enough (or technically limited in some way), the lazarus developers should implement a 'git clean' style tool for the Lazarus project. Or does SVN already have a similar command to git-clean?

I definitely did not rename any directories. Why doesn't 'make clean' rather search for *.ppu and *.o and *.a and executables instead? That would be a much more reliable clean method.

I'd agree with removing .ppu, .o, .a but:
1) removing executables is nasty if you have 3rd party exes in your Lazarus tree
2) IIRC, there's a way to use closed source ppus... if that is true, deleting .ppu might be nasty, too. Possibly similar argument for .o or .a

Perhaps a new make nuclearclean option would be nice that does remove all .ppu, .o and .a files...

Do you know how to do that with Make?

Mattias

Then have a "ignore files filter" file, just like git has. That way you can control what must really stay, and what must go.

Perhaps a new make nuclearclean option would be nice that does remove all .ppu, .o and .a files...

:-)

The clean commands are paired with their counterparts. make clean all
make bigideclean bigideclean

make distclean is a feature of Makefiles created by fpcmake.

That would delete the directories the user added, wouldn't it?

Great.

Maybe if the makefile "clean" is not sufficient enough (or technically limited in some way), the lazarus developers should implement a 'git clean' style tool for the Lazarus project. Or does SVN already have a similar command to git-clean?

I don't know. I never needed to clean up everything. If I want the base state I do an svn export. Sometimes I did a "find . -name '*.ppu' -delete".

Mattias

Mattias Gaertner wrote

Do you know how to do that with Make?

I know nothing about makefile's - for good reason. What I suggested is very simple to implement using Object Pascal. ;-)

Isn't FPC and Lazarus supposed to move away from makefile's anyway?

While I agree with you that too many "clean" targets are not that nice (did you see the "bigideclean" that Matthias wrote? ;) ), I can assure you that "distclean" is rather common among Unix projects.

For a possible explanation see here:
http://www.linuxquestions.org/questions/linux-software-2/what-is-the-difference-between-make-distclean-and-make-clean-284353/

The use in FPC for clean vs. distclean is the following:
* clean removes the generated files (*.ppu, *.a, *.o, etc.)
* distclean ALSO(!) removes the generated fpmake-$target files (they don't need to be compiled on each "make all")

Regards,
Sven

If you follow FPC's trunk, then you'll know that it's already underway rather well ;) (the old INI based Makefile.fpc files in packages are already gone)

Regards,
Sven

Mattias Gaertner wrote

The clean commands are paired with their counterparts. make clean all make bigideclean bigideclean

But both these clean options seem fundamentally broken - as this message thread showed. But thanks for the info though. I'll search the lazarus docs to find out the difference between 'make all', 'make ide', 'make bigidea' etc... There just seems to be too many options with the make command.

As the above example shows, everything that is not tracked by the repository will be deleted. If you wanted to keep something, simply add whatever you want to keep (executables, other files or directories, even regex is supported) to the .gitignore file. Then don't specify the -x option. No some files or directories will be left alone.

A build system can only delete object files that it knows it created. If a build system deletes any other files, it's broken.

This is why you need to do a clean before you update from the repository. Otherwise, directories can move which will leave old compiled units lying around.

It's easy enough to create a clean repo with svn/git, so use that if you're sure you won't delete anything you want to keep.

Henry

Well, every option was needed by someone. That's why they were added.

As far as I can see the "clean" commands to their jobs. If they do what you expect is another thing.

Just add this or that.
Well, I think this not fundamentally better than the current "just do this or that".

It would be better if the user has a simple and intuitive way to find out what the build system does. Maybe a "make help" and a note at the end of "make clean" about "make help".
The same for the coming fpmake.

Mattias

This is unusable if there is only a single file that should *not* be deleted.

Now we have one feature that may delete less than it should, and one feature that may delete more than it should. Real life may reside somewhere in between these extremes...

DoDi

svn status -v | grep -in "?" can return unversioned files, and then they can be deleted ... there's no "clean" option like with git afaik.

zeljko

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

Hans-Peter Diettrich wrote

This is unusable if there is only a single file that should *not* be deleted.

Huh? I really do not understand what you are trying so say. Why would you want to delete all source code etc that came from the repository, and simply leave one mere file standing? In that case, just copy that file out to where ever you want.

The 'git clean' command is used to clean our your cloned repository directory. Thus you WILL want to keep your files that belong to the repository - and maybe one or two exceptions (like the 'lazarus' binary etc). The .gitignore file will in such a case, list the lazarus executable as "ignore this file, by not deleting it".

You end up with a pristine repository - only files and directories that belong and are tracked by the code repository.

The .gitignore file is also use for other things like status / diff information - which files must it show as "new to the repository" etc.

The .gitignore file itself can also be checked into the repository (so everybody shares that file... eg: by default ignore *.ppu, *.o, *.a files form any git actions). If you want a personal list of ignored items, then edit the .git/info/exclude file instead. You can also have multiple .gitignore files in various directories. Those copies would then only apply from that directory hierarchy and deeper.

Anyway, I have no clue what you meant with your reply, so I tried to cover all use bases with my reply.

... which can be 'accidentally' damaged (e.g by format change between versions, rollbacks etc) and what then...? :)

L.

Lukasz Sokol wrote

... which can be 'accidentally' damaged (e.g by format change between versions, rollbacks etc) and what then...? :)

LOL! You better install git so see how funny that statement is.

The file in question looks as follows...

--------[ .gitignore or .git/info/exclude ]------------ # Lines that start with '#' are comments.
# For a project mostly in C, the following would be a good set of # exclude patterns (uncomment them if you want to use them): # *.[oa]
# *~
lazarus
startlazarus
*.ppu
# here the extension can be .o or .a
*.[oa]
# here I want to ignore a whole directory
mycustomfiles/
---------------------------------

There is hardly a "file format" that could be broken. Each line is simply a name of a directory, file or a file mask. Regex could be used too. This are pretty standard stuff if you know what a "file mask" is.

Anyway, it was just a suggestion for a tool for the lazarus project. The current makefile system sucks (too many options, hard to edit, screwed if you got an update before a clean etc), and fpmake might reach the light of day just before I die (I don't plan to die soon). fpmake has its share of problems too, so it will be interesting to see how FPC manages it. I found heaps of problems trying to integrate it with fpGUI. In the end, simple console utilities/tools still rock the house!