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"

(snip)

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

Hi Samuel,
  (snip)

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.

Ray Konopka wrote:
    (snip)

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

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

Hi Craig,
      No, I don't mind at all. Especially, since I don't have mine up yet :)
      Ray
      (snip)


      

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

(snip)

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

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

Ray Konopka wrote:
    (snip)

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

Hi Anthony,
      (snip)

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.

Ray Konopka wrote:
        (snip)

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.

Ray Konopka wrote:
        (snip)

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.
        --

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

(snip)

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

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.

Hi Lucian,
          This is why the {$LIBSUFFIX 'nn'} directive is in its own
          include file. It's a workaround for this problem.
          Ray
          (snip)

(snip)

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

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.

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

Hi Lucian,
                  (snip)

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. :)