[Lazarus] I desperately need some ideas of reducing edit, compile, debug cycle
Sven Barth
pascaldragon at googlemail.com
Sat Nov 27 12:14:23 CET 2010
On 27.11.2010 12:01, Frank Church wrote:
>
>
> On 26 November 2010 20:55, Martin <lazarus at mfriebe.de
> <mailto:lazarus at mfriebe.de>> wrote:
>
> On 26/11/2010 19:56, Frank Church wrote:
>
>
> One thing that has always gottem to me when using Delphi and now
> Lazarus is the tedious edit, compile, debug cycle. It has been
> growing worse of late that now I am beginning to dread the whole
> process any time I have to make some changes, especially when
> they are just minor GUI changes.
>
> ....
>
>
> Quite simply I am thinking of a way to create the application in
> parts, so that the parts containing the new functionality can be
> developed separately as standalone programs, perhaps even
> console programs.
>
> This raises the question of how procedure parameters and results
> can be passed, and these are the options that have initially
> come to mind.
>
> 1. Find a way to automatically translate simple variables,
> record structures, or objects into text and pass them via the
> command line or pipes. Perhaps JSON, XML or simple name-value
> pairs can be used here. Designing the parameters as TPersistent
> objects that are streamed into text form may be a better option
> here.
>
> 2. Rather than using the command line, make them network
> services and pass the parameters that way, or may make them
> RESTful/XML-RPC with all the new webby stuff( I am getting into
> some of that stuff now)
>
> 3. Design them as DLLs initially - I suspect that will bring
> along a different set of problems.
>
> Once they are well tested I can incorporate them into the main
> executables.
>
>
> Yes splitting your project into parts is a good idea. Quite simple
> use packages.
>
> Then you still have one application, you still can pass data around
> in the normal pascal way.
>
> Each package can be tested with a small simple runner application,
> or even better a fully automated testcase.
> Testcase are especially useful, if you can extract the functional
> layer from the visual layer.
>
> So instead of writing something big into
> TForm.SaveDocumentButtonClick, you just have "TheDocument.Save" in there
> => all functionality goes into a none visual object TheDocument
> (or whatever it is in your case).
> - this object takes instruction, if the user clicks something
> - it can be asked what to display.
> - it can be given callbacks, if it requires to notify the visual layer.
> for example it can have "OnTitleChange" => which is linked to a
> method changing the forms Caption (Title)
> ....
>
> Martin
>
>
> --
>
>
>
> Thanks for the reply, Martin.
>
> Are there some code examples which use this approach, especially the
> package based one?
>
> Will it also reduce the size of the debugging exe or speed up its creation?
>
It will speed up its creation, cause if you didn't touch a unit in a
package it isn't recompiled. The size of the EXE won't be changed (see
below).
> Sometimes I see only one file compiled, then it goes to the linking
> phase, but it doesn't seem to reduce the exe size or the speed of its
> creation.
That's because only one file needs to be compiled.
It does speed up the compilation (a little bit), cause the compiler only
needs to load the ppus not to recompile their units. And it would be a
very bad sign if that would reduce the EXE size, cause that means that
code would not be compiled in that otherwise would be in there.
Regards,
Sven
More information about the Lazarus
mailing list