Package Names

[samuel herzog]

I trying to move from D7 to D2006 and found out that most of us
did not understand how the naming of package should have been done.

Now it is to late and we are forever bound to that.

rule 1.) No package-filename (.dpk) should include any reference to a
Delphi Version. So "PackageXYZ_D7.dpk"

Anyone else has a comment about that ?

[Liz]

>rule 1.) No package-filename (.dpk) should include any reference to a
>Delphi Version. So "PackageXYZ_D7.dpk"
>
>Anyone else has a comment about that ?

Pre d7 or so, I dont think people thought much about setting these rules,
some companies/developers did this, as the various versions changed a lot,
however, it wasnt as much of a common practice, I guess in a way as the
internet was still young and there were less discussions about it.

If you think in d5 for example if you wrote a component of your own, you
added it to the default user package within delphi. 2005 stopped this, you
needed to make a package too, and because 2005 and 2006 share the my
documents\borland studio projects\bpl directory, its now more important
than ever - although if you used runtime packages and so forth mutli
versions needed to be able to be run.. or at least you wanted it so you
could use multi versions it had not to clash.

--
Liz the Brit
Website http://www.xcalibur.co.uk/DelphiThings

--- posted by geoForum on http://delphi.newswhat.com

[Ray Konopka]

Hi Samuel,

In early versions of Delphi, you pretty much had to put the VCL version
number into the name of the package. This was because if you were
going to support multiple versions of the VCL then you needed to create
separate BPL files for each version of the VCL.

Starting with Delphi 6, you can use a single DPK file without reference
to the VCL number and then use the {$LIBSUFFIX } directive to have
the output BPL file include the appropriate VCL version. The other
nice benefit of this is that the DCP file for the package does NOT include
the VCL version. Therefore, any packages that require your package,
do NOT need to be edited when recompiled for a new version of Delphi.

For example, for our Raize Components product, the following files are
used:

Package Source Files:
RaizeComponentsVcl.dpk
RaizeComponentsVclDb.dpk

Package DCP files: One set created for each version of VCL
Lib\Delphi7\RaizeComponentsVcl.dcp
Lib\Delphi7\RaizeComponentsVclDb.dcp
Lib\BDS2006\RaizeComponentsVcl.dcp
Lib\BDS2006\RaizeComponentsVclDb.dcp
. . .

Package output files:
RaizeComponentsVcl70.bpl
RaizeComponentsVclDb70.bpl
RaizeComponentsVcl100.bpl
RaizeComponentsVclDb100.bpl
. . .

Ray

[Allen Bauer (Borland/DTG)]

Ray Konopka wrote:

I'm glad *somebody* recognized the value of that effort and has taken
advantage of it... :-)

--
Allen Bauer
Developer Tools Group
Chief Scientist
Borland
http://blogs.borland.com/abauer

[Craig Stuntz [TeamB]]

Thanks, Ray, for an informative post. Mind if I copy it to my blog?

--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt
your DBs! Open Edition users, get 6.0.1.6 from http://mers.com

[Ray Konopka]

Hi Craig,

No, I don't mind at all. Especially, since I don't have mine up yet :)

Ray

[Craig Stuntz [TeamB]]

http://blogs.teamb.com/craigstuntz/archive/2006/10/25/libsuffix.aspx

--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz

Borland newsgroup denizen Sergio González has a new CD of
Irish music out, and it's good: http://tinyurl.com/7hgfr

[Lucian]

> Starting with Delphi 6, you can use a single DPK file without
> reference to the VCL number and then use the {$LIBSUFFIX } directive
> to have the output BPL file include the appropriate VCL version.

Hi Ray,

The suffix is included in the source of the DPK file. So, if you have
to maintain a package for multiple versions of Delphi, you would have
to take care of *that* every time you compile the package, to make sure
the suffix is the one you need at the moment. Practically, the
directive is cool if you just go up with your package and never need to
compile it with a lesser version of Delphi. I think that's why this
feature is practically unused by big component players, as far as I can
see.

If the suffix (and other) would be saved in other file, Delphi version
specific, than it would be really cool. I'm thinking at .dof files. Too
bad they were not meant to go up with the Delphi version, either with
small name adjustment, or using same file name, but different content,
kind of .ini (xml), something like

[Delphi6]
LIBSUFFIX=60
..other crap

[Delphi7]
LIBSUFFIX=70
..other crap

regards,

Lucian

[samuel herzog]

Yes, thats exactly the way it should be.
So I started to change the names of my packages. Removed the D7 and tried to
compile the stuff by
command line compiler for D7 and D2006 and what a surprise ;-)

My Package has in the "requires" statement some packages which have also
Post-Fix "D7". e.g. JVCL components.

So I had to go back to the old package naming :-(
That's the reason why I think we will never get out of that problem.

"Ray Konopka" <rkon...@raize.com> wrote in message
news:453fae36$1...@newsgroups.borland.com...

[Ray Konopka]

Hi Lucian,

Well, I like to think that Raize Components is one of the big component
players, and we do use this particular feature, and we do support
multiple versions with our product.

And yes, as you note for developers building for one version of Delphi
and upgrading to a newer version things are much easier. However,
even a component provider supporting multiple versions of Delphi
can take advantage of the LIBSUFFIX as well.

In particular, our RaizeComponentsVcl.dpk file looks like this:

{$I RzComps.inc}

package RaizeComponentsVcl;

{$R 'RaizeComponentsVcl.res'}

{$ALIGN 8}
//... other directives deleted
{$IMPLICITBUILD OFF}
{$I RaizeComponentsVcl_Description.inc}

{$IFDEF VCL60}
{$I RaizeComponents_LibSuffix60.inc}
{$ENDIF}
{$IFDEF VCL70}
{$I RaizeComponents_LibSuffix70.inc}
{$ENDIF}
{$IFDEF VCL90}
{$I RaizeComponents_LibSuffix90.inc}
{$ENDIF}
{$IFDEF VCL100}
{$I RaizeComponents_LibSuffix100.inc}
{$ENDIF}

requires
Vcl,
VclX;

{$I RaizeComponentsVcl_Contains.inc}

end.

The LibSuffix include files simply have the {$LIBSUFFIX 'nn'} directive
listed. The appropriate include file isused based on the defines
established
in the RzComps.inc file.

And yes, it is a bit cumbersome for us to setup, but once it's done, we
do not have to change it. What's more important, is that our customers
simply reference RaizeComponentsVcl.dcp in their packages, and they do
not have to do anything when they switch versions of Delphi.

Ray

[Lucian]

> {$IFDEF VCL60}
> {$I RaizeComponents_LibSuffix60.inc}
> {$ENDIF}
> {$IFDEF VCL70}
> {$I RaizeComponents_LibSuffix70.inc}
> {$ENDIF}
> {$IFDEF VCL90}
> {$I RaizeComponents_LibSuffix90.inc}
> {$ENDIF}
> {$IFDEF VCL100}
> {$I RaizeComponents_LibSuffix100.inc}
> {$ENDIF}

But than you fall into the problem with the IDE screwing up projects
having {$IFDEF}, an old bug as old as Delphi and for some reasons
impossible to fix :-)

I understand that you are not using the IDE to edit the DPK files...

Lucian

[Lucian]

The QC bug ids for IDE dropping IFDEF's are:

8718/ 33284/ 21339

Maybe it's time this problem gets more votes, otherwise all features
similar to LIBSUFFIX that get saved into the .DPK file are ... just a
waste of time because thet are not really usable.

Lucian

[Anthony Frazier]

Ray Konopka wrote:

> NOT include the VCL version. Therefore, any packages that require
> your package, do NOT need to be edited when recompiled for a new
> version of Delphi.
>
> For example, for our Raize Components product, the following files are
> used:
>
> Package Source Files:
> RaizeComponentsVcl.dpk
> RaizeComponentsVclDb.dpk
>
> Package DCP files: One set created for each version of VCL
> Lib\Delphi7\RaizeComponentsVcl.dcp
> Lib\Delphi7\RaizeComponentsVclDb.dcp
> Lib\BDS2006\RaizeComponentsVcl.dcp
> Lib\BDS2006\RaizeComponentsVclDb.dcp

So how does one get the .dcp (and more importantly, the .dcu) files
into version specific folders?

--
Pax,

Anthony Frazier
Victor Printing, Inc.

[Ray Konopka]

Hi Lucian,

This is why the {$LIBSUFFIX 'nn'} directive is in its own
include file. It's a workaround for this problem.

Ray

[Ray Konopka]

Hi Anthony,

> So how does one get the .dcp (and more importantly, the .dcu) files
> into version specific folders?

Now were getting into supporting multiple versions (simulatneously)
with the same package source file. For most developers, this will
not be an issue, but for component developers wanting to support
multiple versions of Delphi, it is something that needs to be addressed.

With that said, it is quite easy handling this. After we build the
package for a specific version of Delphi, we simply copy the
DCP file to the appropriate Lib\* directory.

Ray

[Lucian]

> This is why the {$LIBSUFFIX 'nn'} directive is in its own
> include file. It's a workaround for this problem.

Ray, I was saying that you can not edit the DPK file in the IDE because
you risk having the IDE delete all your ifdefs. Of course the file
works in all Delphi editions after D5 ... as long as you don't need to
edit it in the IDE (say you need to add another resource file, or you
want to disable some new annoying hint/warning that comes up with a new
Delphi version).

For instance, I do use packages for D5,7,2006 on a daily basis, they do
change pretty often, in content or files included, etc. If I would be
using the LIBSUFIX, I'd be dead by now of heart attack or something.

--
regards,

Lucian

[Ray Konopka]

Hi Lucian,

You did not understand my post. By using the include files to specify
the LIBSUFFIX, then you *can* edit the DPK file in IDE. If you use
the LIBSUFFIX directly, then the IDE will remove all but the last
reference to it.

Ray

[Hans-Peter Diettrich]

Ray Konopka wrote:

>>So how does one get the .dcp (and more importantly, the .dcu) files
>>into version specific folders?
>
>
> Now were getting into supporting multiple versions (simulatneously)
> with the same package source file. For most developers, this will
> not be an issue, but for component developers wanting to support
> multiple versions of Delphi, it is something that needs to be addressed.

Again FPC seems to have more appropriate solutions, based on additional
compiler arguments, as required for cross compilation. The Borland tools
are too much fixed on a single-compiler-single-target view, not
addressing developers of multi-platform applications or components.

DoDi

[Lucian]

It has nothing to do with LIBSUFFIX residing in files being included.
It has to do with the fact the included files, the stuff {$I blah} is
enclosed between IFDEF and fact is the IDE deletes the IFDEFs (and I am
sure you know that very well).

I think I misunderstood you maybe, you were referring to actually
editing the file in the editor and I was actually saying you can not
use the package editor (or package manager, whatever is called).

I still say that what you do is risky and I would not advise people to
follow upon your idea, unless they clearly understand NOT to use the
package editor/manager from the moment they choose to put IFDEFs in the
DPK/DPR files. Actually that was my point all along.

Lucian

[Ray Konopka]

Hi Lucian,

> I think I misunderstood you maybe, you were referring to actually
> editing the file in the editor and I was actually saying you can not
> use the package editor (or package manager, whatever is called).

Yes, the package editor with the tree nodes for specifying Contains
and Requires does indeed cause problems. Which is one of the
main reasons that we do not use it, which of course, is the point
you were making. :)

Ray

[Anthony Frazier]

Ray Konopka wrote:

> With that said, it is quite easy handling this. After we build the
> package for a specific version of Delphi, we simply copy the
> DCP file to the appropriate Lib\* directory.

I thought it would end up being something along those lines. Or using
dcc32 to do the compilation and specifying the various output folders
based on the Delphi version being targeted.