[Lazarus] Clean Up + Build all

[Mattias Gaertner]

On Mon, 6 Dec 2010 17:24:08 +0300
Max Vlasov <max.vlasov at gmail.com> wrote:

> On Mon, Dec 6, 2010 at 12:12 PM, Kjow <antispammoni at gmail.com> wrote:
> 
> > Hi all,
> >
> > what is the equivalent on command line of the "Clean Up + Build all" in the
> > IDE?
>
> > With:
> >  make bigideclean bigide OPT="-Xg"
> >  lazbuild --build-ide=
> > I don't have the same result.

Do you want to emulate how the IDE builds or do you want to get the
same output?

First: you can not exactly do the same easily
Second:
make clean all 
make clean all -w examples
lazbuild -B --build-ide=


>[...]
> Theoretically sometimes the IDE (automatically) and you (in the custom
> option) can append -B switch that forces fpc to rebuild all the units of the
> project unconditionally, but  the problem lays in the packages your project
> depends upon. When Lazarus prepares the parameters for fpc, it basically
> appends the paths containing compiled units of the packages, so if it gets
> -B switch, fpc can not reach the unit sources, so builds the project with
> the compiled version. And I don't know whether the problem is solvable since
> packages is a special entity in Lazarus treated in special way but maybe I'm
> wrong.

The same logic applies to packages: If the options change for a package
the package is compiled with -B.

 
> Personally when I use Delphi 'Build' that actually rebuild every reachable
> source file, I do this for two reasons
> 1. I have a global define for some profile/debug work so I have to be sure
> that the code is reverted to non-debug state after
> 2. For psychological reasons, I feel safer this way before release :)
> 
> Surprisingly Lazarus correctly tracks the first case, when you manually
> change global define (-d) (but as I said without sources that reside in
> other packages). As for second reason, in my case it's unbeatable :)

Lazarus packages are independent entities. The package
developer has tested the sources with some flags and these are stored
in the lpk and used when a user compiles the package. This has
several advantages. Here are some of them:
- it allows to share the package ppu files with various projects
- if you spot a bug in the package you can give the package maintainer
  reproducable bug reports.
- making it harder to compile a package accidentally with
  untested/unsupported flags
- you don't need the notorious include
  files of Delphi packages with many compiler defines
- avoiding name clashes with IFDEF flags.

Since 0.9.29 a package can have optional flags.


Mattias