Helen, all,

H> oic. Well, it's not what's supposed to happen. If you put your bpl path
H> in the library list, it's supposed to look there for the libraries. For
H> some packages, it's essential, as not everyone conforms to the naming
H> rules. One component pkg's bpls can overwrite another's if everything gets
H> blatted unconditionally into the system directory.

if package vendors ever overlap names, then you'll be having problems
even if the binaries are in different directories, since the
linker (at compile time) and the application (at run time) won't be
able to find any instance but the first in the path list. So keep your
fingers crossed anyway (or trust the package vendors, which is what I
do).

Putting all the bpl and dcp files in a single directory (not the
system32, perhaps better $(DELPHI)\Projects\Bpl, as is the default
setting) is actually a good idea because it eases development:
programmers that don't need to debug or recompile packages just need
that directory synchronized to be able to work - it's invaluable in
medium to large teams (they also need the dcu/dfm/res files if they're
not using run time packages, but I almost always go for them). It also
eases deployment, since installers know that everything needed is
found in only one place.

H> Most versions of Delphi behave as expected, but the rogue editions cause
H> real pain and sometimes outright insanity.

I am not aware of such problems in any version of Delphi. Or, better,
I haven't run into problems so far. From my experience, search path
order, dependencies, global settings vs project settings often make it
very difficult to understand what goes on, even if it's not due to bugs.

Ciao
--
Nando Dessena
mailto:nandod@...