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/ -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
