[Lazarus] How would you organize build directories for different versions?

Graeme Geldenhuys graemeg.lists at gmail.com
Thu Jul 14 12:39:27 CEST 2011


On 07/14/2011 12:20 PM, Mattias Gaertner wrote:
>  > And that can cause it's own set of headaches. Yes it saves on disk space 
> No, it needs more disk space, because you have several output directories per
> package, .e.g. targetcpu-targetos.

I think you missunderstood my statement. I meant that using Lazarus
Packages allows you to save on a bit of disk space. So if 10 projects
are using the LCL package, you only have one set of target *.ppu files
for the LCL package.

> AFAIK it is quite the opposite.
> If all project options would be applied to all packages, that means applying
> options to code you have not written, you can get very undesirable results.

Here is an example:
I have a project that uses 'fpgui', 'onguard' and 'tiopf'. If I compile
each of those libraries with unoptimized and very verbose compiler
settings - that is helpful while developing and for debugging. But now I
want to generate a release build of my project. I can't just toggle the
release build settings in by project settings, because those will not be
applied to the 3 libraries (lazarus packages) I use. So I have to
individually change the settings for each of those 3 packages and
recompile them, then recompile my project.

Whereas if I used a single unit output directory, my project compiler
settings will be applied to all source code (even the 3 libraries I use)
when I include the -B compiler parameter. Now ALL source code will have
the optimized "release build" compiler settings applied to them. One
change of compiler settings and one re-compile.


> The main idea for separate output directories is that you can be sure that the
> package units are compiled with the options the package developer tested it.

I am the package developer and the project developer. So I guess my use
case must be unique then [though I doubt that].


>  > The other problem being that sometimes Lazarus doesn't detect unit
>  > changes and doesn't "auto" recompile those related packages. Also
>  > causing huge frustration. 
> You told so once and said you would tell me how to reproduce it once it appears
> again. But I didn't receive no such mail. Now you write again that the IDE is
> buggy - again without any clue.
> This is not helpful.

Yes, and I run the Lazarus IDE via the command line (as requested) for a
week without any new information to report. The issue is not instantly
reproducible, so it is rather difficult to be more "helpful" with the
bug report.


>  There are many ways to maintain your code base. It is good that the IDE
> supports a lot.

+1
That was the whole point of my post. You stating that "Lazarus Packages"
is the saviour compared to Delphi unit paths is not always 100% correct.
Depending on use cases, either method can be the "ideal method" of
working with your code.



Regards,
  - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/





More information about the Lazarus mailing list