Re: Build with packages

Hi there

Answers inline:

"Patrick Moloney" <NewsID*at*SandrockSoftware.c*o*m> wrote in message
news:45bdb142$1@xxxxxxxxxxxxxxxxxxxxxxxxx
I wish I could find a better place to post this question but I resort
to non-technical.
Looking for advice on building with packages - as opposed to one exe. I
realize it's all-or-nothing. You can't just add your own packages, you
have to convert all your code to packages, meaning include numerous
core delphi packages for code you've used. So, before I make any new
changes, how much work will I have to do to convert an existing app to
use packages. If I just check the box, what errors will I get?

You shouldn't get any errors. It should just work.
The 'Build with packages' option in the Project Options dialog
should already have a list of packages something like

rtl;vcl;vclx;dbrtl;...etc...

If you just check the box and *rebuild* your project
then you should see that the EXE file size has reduced.
The Project-Information dialog will show you which of
the runtime packages your project actually requires.
These can be redistributed with your EXE. They are usually
installed by Delphi into C:\Windows\System32, but when
you redistribute them, you can safely just put them in your
application's dir.

Then to do it right, I should break the application into logical
packages of some sort. How would that best be done - by major menu
groups? (These are typical business applications).

This is a separate issue. If you have code or forms which are shared
between applications, you could think about putting this code/these
forms into packages. To do this you will need to consider your
object hierarchy and unit dependence. Creating your own packages
is not a trivial task.


At what point does all this make sense anyway? The simplicity of a
single exe is attractive - until a point. But it's not the problem it
once was either.

The main advantage of using packages (either the Delphi runtime packages
supplied by Borland, or your own packages) is to reduce the size of
files for deployment. If you have 2 applications, compiling without
packages means both exe files contain copies of all the RTL and VCL code.
Compile with packages, and neither exe contains this code, but you must also
deploy the RTLxx.bpl and VCLxx.bpl files (and other required BPLs).

Using packages can also help the OS optimise the use of RAM when the
EXEs are loaded. If your programs are often run simultaneously,
then loading each program will be quicker, since the packages will already
be present in memory.


Ultimately, I see the promise of attaching some custom feature to one
installation but not to another. I've seen some tidbits of this
described using packages.


Optional plugin behaviour can be implemented using packages, or
using DLLs, or using COM (another specialisation of DLLs).
Whichever method you use, you need to have a decent abstracted object
model first.


Finally, I recall looking at implementing dlls in Delphi for a large
app some years ago and there was a significant problem sharing global
variables. I hope packages aren't as isolated.

I will appreciate any insights.

DLLs can only export functions and procedures. They cannot export
classes or global variables. Delphi BPLs (packages) are DLLs on steroids.
They have some fancy plumbing to enable them to export classes and
share the memory manager (and thus global variables) with the main
exe, and with other packages.

Creating your own packages can cause deployment versioning problems,
since if you change anything in the interface sections of any of your
units in the packages, they become incompatible with the pre-existing
exes, and you find that you have to keep recompiling everything
with every minor change.

However, using the existing Delphi runtime packages is very straightforward,
and should cause you no problems at all. If you have a large number
of EXE files then just compiling all EXEs with runtime package support
enabled
can substantially reduce the filesize of your setup.

Hope this helps.

Cheers,

Chris


.

Relevant Pages

  • Re: Help choosing Delphi version?
    ... But it is contained within the EXE. ... The point here is that Delphi gives ... > or you can distribute an executable that requires packages. ... > reason to do the latter would be to distribute a suite of applications ...
    (alt.comp.lang.borland-delphi)
  • Re: Debug info
    ... > I have a relatively large application which comprises of one EXE (quite ... > The vcl suite of packages however, cannot be re-built with debug info as we ... > than the BPL as the currently selected package in delphi and relying on the ...
    (borland.public.delphi.ide)
  • Re: Help choosing Delphi version?
    ... But it is contained within the EXE. ... This is the main reason why a typical Delphi application ... I avoid it by not using packages. ...
    (alt.comp.lang.borland-delphi)
  • Re: Package location for runtime executable
    ... I am guessing no, because as part of the exe startup, it ... > that will run within the exe, that will specify a sub-directory. ... packages offer the needed functionality, ... can be registered in the Windows registry under the ...
    (borland.public.delphi.language.objectpascal)
  • Re: Projektorganisation: Wie den =?ISO-8859-1?Q?=DCberblick_=FC?= =?ISO-8859-1?Q?ber
    ... Bedarf mit oder ohne Packages linken. ... Ich brauche aber immer alle DLLs. ... Wenn Du alles in einer Exe brauchst, dann linkst Du die eben ohne Packages - dann kommt alles in eine große Exe. ... Und wenn Du zum Vertrieb eine kleine Exe + DLLs haben möchtest, linkst Du die mit Packages, und mußt dann die kleine Exe und die ganzen zugehörigen Packages ausliefern. ...
    (de.comp.lang.delphi.misc)