3rd party component installation strategy
Frank Marousek
process of migrating from Delphi 5.
First up is installation of third party components. In my previous D5
installation, my third party components tended to be scattered all over the
place, resulting in a very disorganized setup. This result was mostly due to
my being a new Delphi user when I first started installing the third party
components and not being exactly sure what was going on.
I would like to try to keep my installation of third party components more
organized with D2007. Is there a particular strategy that you all employ as
far as where components are stored and such?
Any and all comments appreciated.
Nathanial Woolls
> Any and all comments appreciated.
I personally install all my components under X:\Program
Files\CodeGear\Components (rather than C:\Program Files).
Markus.Humm
I made a subdirectory in the Delphi main directory. Each component gets
its own subdirectory there.
Greetings
Markus
Tom Corey
> Is there a particular strategy that you
> all employ as far as where components are stored and such?
While normally I think the c:\Program Files folder is a really good
concept, there are a few situations where I don't consider it ideal. My
programming tools is the best example. I install my compilers right off
the root. For example c:\D5 and c:\D2007.
I often had/have multiple compiler versions installed at once. At work,
it's D5 and D2007. At home it was D7 and D2007 - I recently dropped D7
as D2007 is a much better tool. Since I was/am dealing with multiple
compilers yet wanted my component libraries centralized, I installed
them under a common location - c:\DLibs - rather than in the program
files heirarchy or under the individual compilers.
Having my compilers and libraries so near the root makes it far easier
to do backups, file maintenance, and navigate.
Alessandro Federici
news:4761...@newsgroups.borland.com...
[..]
> Any and all comments appreciated.
1) I have a few system variables such as $ROVCL, $DAVCL, $DXVCL to avoid
having to use full path names in the Delphi's "search library" option.
2) I install stuff always and only under d:\vcl70 (and for instance, $ROVCL
would be "d:\vcl70\RemObjects SDK For Delphi")
3) I also renamed the folder "C:\Program Files\Borland\Delphi7\Projects\Bpl"
to "<..>\Bpl !!! NOT HERE !!!" so that I can make sure that those component
sets that don't output in proper paths will not compile. I then adjusted
them (they aren't many and this does not happen with professional component
sets that I know of or I use).
That's pretty much all I do and it helps making sure thing are in order and
you know where to find stuff.
James Miller
Do not install third party components on your 'clean' development machine. Instead,
install the components on a 'dirty' machine, and then manually take the source code
of the components to their own subdirectory under a Delphi version specific folder
on the 'clean' machine. All my Delphi 2007 components are, for example, in their
own directories under "C:\Vcl2007\" folder.
Edit the packages so that all directories point to the right places. I usually set all
directories to blank, so dcu files go in the same directory where the source is,
and bpl and dcp files go to the Delphi's default locations under Documents and
Settings that are already on the search path.
Be careful if you need to distinguish between debug and release versions, in that
case it is probably better to have DEBUG and RELEASE subdirectory trees for all
computer generated junk, kind of like Visual Studio does it. But you will have to
do extra work with search path in this case.
Now, compile the components, and install the design time packages into the IDE.
Andreas Hausladen
> I usually set all
> directories to blank, so dcu files go in the same directory where the
> source is,
That is the main reason why the Delphi compiler takes ages to compile a
project. It must look in hundreds of directories for the *.dcu file.
--
Regards,
Andreas Hausladen
Andreas Hausladen
> Does it run faster if all dcu files are put in single directory?
Yes. The compiler is faster if there are only a hand full directories
in the "Library Path".
> There could be potential name collisions, as different component
> vendors use different naming conventions (or no conventions at all).
There won't be any name conflicts If the units are organized in
packages, because the IDE itself prevents you from loading a package
that contains a unit that is already loaded by a different package.
--
Regards,
Andreas Hausladen
James Miller
"Andreas Hausladen" <AndreasDO...@gObviousToBeRemovedmx.de> wrote in message news:4761...@newsgroups.borland.com...
> > I usually set all
> > directories to blank, so dcu files go in the same directory where the
> > source is,
> That is the main reason why the Delphi compiler takes ages to compile a
> project. It must look in hundreds of directories for the *.dcu file.
Does it run faster if all dcu files are put in single directory? There could
Zoren Lendry
> There won't be any name conflicts If the units are organized in
> packages, because the IDE itself prevents you from loading a package
> that contains a unit that is already loaded by a different package.
I just got done putting all my third-party dcu's in one folder (and
removing all the other paths from the knowledge of Delphi). It does
compile somewhat faster. I did the "one folder dingus" not because of a
need for faster compile times, but for faster Code Completion times.
The only problem I had was that some of the RemObjects units that I
wanted the .pas file for expected the .inc file to be in the parent
directory, and so I had to make copies of them in the parent of my Dcu
folder.
Yeah, it's a bit of a pain when I upgrade libraries, but the IDE is more
responsive for big projects.
Loren
Paul Dolen
product installed in C:\Program Files\Borland\Delphi?, I would put all
my components under that. That way the library path for all
components was $(DELPHI)\ xxx
So, when they changed to BDS, I was annoyed and decided to use custom
directory of C:\Program Files\Borland\Delphi9 for 2005 and C:\Program
Files\Borland\Delphi10 for 2006, and still put everything under it. So
I was still using the same idea.
Well, now that you're not really supposed to do that with Vista, well,
I've just given up on organizing, and just let the compiler and
components install wherever they feel like it. I may never upgrade
from 2007 simply because upgrading components is such a PIA and I've
given up all hope of organization.
If I could go back in time and put a gun to somebody's head to change
one feature of Delphi, I'd force somebody to design a standardized
component installer for Delphi 2.
James Miller
> > vendors use different naming conventions (or no conventions at all).
> There won't be any name conflicts If the units are organized in
> packages, because the IDE itself prevents you from loading a package
> that contains a unit that is already loaded by a different package.
I am sorry, but I don't think this is correct. IDE allows same unit names
as long as they are in different packages. Even loaded in the project manager
at the same time.
Tony Caduto
> I personally install all my components under X:\Program
> Files\CodeGear\Components (rather than C:\Program Files).
That is where I put mine also.
Dave Nottage [TeamB]
> Any and all comments appreciated.
FWIW:
I have one directory where all 3rd party bpl's go.
eg: S:\Bin
I have one directory for each corresponding version of Delphi where all
3rd party DCU's and other library files (eg .RES files) go.
eg: S:\Lib\D7 or S:\Lib\D2007
Fortunately I haven't had any name collisions for either.. yet. I
suspect it's more likely for DCUs etc, however most 3rd party
developers are kind enough to prefix unit names which has helped avoid
collisions.
It would be nice if 3rd party developers provided an
"I-know-what-I'm-doing" option for installations, so that I could just
nominate the two directories mentioned above.
The above method makes it a *lot* easier to find the files, and to set
up other machines with the same packages.
--
Dave Nottage [TeamB]
Henrick Hellström
> 1) I have a few system variables such as $ROVCL, $DAVCL, $DXVCL to avoid
> having to use full path names in the Delphi's "search library" option.
> 2) I install stuff always and only under d:\vcl70 (and for instance,
> $ROVCL would be "d:\vcl70\RemObjects SDK For Delphi")
> 3) I also renamed the folder "C:\Program
> Files\Borland\Delphi7\Projects\Bpl" to "<..>\Bpl !!! NOT HERE !!!" so
> that I can make sure that those component sets that don't output in
> proper paths will not compile. I then adjusted them (they aren't many
> and this does not happen with professional component sets that I know of
> or I use).
You forgot to mention that in order for that to work, you have to add
your paths to the system PATH environment variable. (Which, btw, is why
recommended against your approach. Having a short PATH is the best way
to avoid some installer eventually corrupting it. And in order to have a
short PATH it is actually better to drop .bpl and .dcp in a directory
that is already on the PATH - such as the \Bpl directory!)
Andreas Hausladen
> I am sorry, but I don't think this is correct. IDE allows same unit
> names as long as they are in different packages. Even loaded in the
> project manager at the same time.
The project manager does not load the package, it opens the source. If
you have a look at the SysUtils.InitializePackage function, you will
see that there is a call to "CheckForDuplicateUnits". And guess what
this function does at runtime.
--
Regards,
Andreas Hausladen
Q Correll
| Do not install third party components on your 'clean' development
| machine. Instead, install the components on a 'dirty' machine, ...
Why?
--
Q
12/13/2007 15:04:52
XanaNews Version 1.17.5.7 [Q's salutation mod]
Marius
k:\components7\ folder. Subdirectories there contain all thirdparty
packages and i share the bpl's and subdirectories with other delphi
installations. I convert each TP to use this solution.
I have had many filename collisions so i leave them in the source
directories to avoid troubles (bad habits naming units).
Greetings,
Marius
Bill Bonde
as long as the units are in different packages; installed design time
packages too. As such, dumping all dcu files in a single directory
has a potential of conflict.
Dave Nottage [TeamB]
> One can have multiple units with the same name loaded in Delphi
> as long as the units are in different packages; installed design time
> packages too.
If you're able to do that, please post example packages that
demonstrate it to borland.public.attachments.
--
Dave Nottage [TeamB]
Bill Bonde
"Dave Nottage [TeamB]" <david...@radsoft.com.au> wrote in message news:4761fb5e$1...@newsgroups.borland.com...
> If you're able to do that, please post example packages that
> demonstrate it to borland.public.attachments.
An example screenshot is now in the borland.public.attachments.
Dave Nottage [TeamB]
> An example screenshot is now in the borland.public.attachments.
I'm curious as to why the requires clause is not expanded for
ExtraPackageDesign. I suspect it's because Package1 is included, ie
ExtraPackageDesign doesn't actually contain the ComboBoxColumnsEdit
unit, Package1 does.
--
Dave Nottage [TeamB]
Bill Bonde
> ExtraPackageDesign.
It doesn't really matter. That requires clause contains the following packages:
rtl,
ExtraPackageRun,
DesignIDE,
vcl;
Where ExtraPackageRun is a runtime package, and the rest are part of Delphi.
The Package1 was created long after any changes to ExtraPackageDesign package
and its surrounding files.
> I suspect it's because Package1 is included, ie
> ExtraPackageDesign doesn't actually contain the ComboBoxColumnsEdit
> unit, Package1 does.
No, it's not included. I don't want to post my actual working code,
but would you like me to create an example with two test packages that contain
identically named pas unit files, where these packages can be installed into
Delphi 2007 simultaneously?
vavan
<AndreasDO...@gObviousToBeRemovedmx.de> wrote:
>That is the main reason why the Delphi compiler takes ages to compile a
>project. It must look in hundreds of directories for the *.dcu file.
on the other hand iirc I've read somewhere that file operations slow
down if there are several thousands of files in the same directory so
perhaps it's some kind of trade-off...
--
Vladimir Ulchenko aka vavan
yannis
yes please I am unable to do so and I would like an example to study.
Thank you.
Yannis.
David Perkins
go in c:\dev\cmp\bpl. All projects go under c:\dev\
Bruce McGee
This is what I do.
Each version of Delphi has its own BPL directory, and each
component/library has a separate lib directory for each version of
Delphi that I'm using.
It keeps everything together and makes it easier to recompile for new
Delphi versions as required. It also makes it easier to manage some
code that I don't necessarily want to install into the IDE(s). I
started this when I was developing Indy9 and Indy10 projects at the
same time, so I just changed the individual project paths and
instantiate the components dynamically.
A friend also had a good idea to rebuild and install all the third
party controls from this common path with an automated build process.
I'm just getting started, but it sure will make my life a lot easier
moving to another development machine or setting up another build
server.
--
Regards,
Bruce McGee
Glooscap Software
Florent Ouchet
You can load multiple packages containing the same unit only if they are
marked as weak ($WEAKPACKAGEUNIT) which is bad...
Dave Nottage [TeamB]
> I don't want to post my actual working code,
> but would you like me to create an example with two test packages
> that contain identically named pas unit files, where these packages
> can be installed into Delphi 2007 simultaneously?
Sure. As Florent says, they can't have {$WEAKPACKAGEUNIT} either,
because it's not the same thing.
--
Dave Nottage [TeamB]
Lucian Radulescu
Maybe I need new glasses .... what exactly is the duplicate file name?
I see
1. ComboBoxColumnsEdit.pas
and
2. ComboBoxColumnsEdt.pas
Lucian
Lucian Radulescu
Forgot to mention... I moved from System32 to the BIN folder, all BPLs
that belong to a Delphi edition, before installing a higher edition
number. So, I don't have any BPLs (or other crap like JDBG or XML) in
system32 and that's how I could ran in the past side by side Delphi
2006 and 2007. (This requires some minor changes to the registry, for
Delphi 5 which points a bpl to system32 folder.)
Lucian
Lucian Radulescu
Easy and fast backups, no re-installs problems, easy to find the files.
I'm structured like this:
A. Delphi compilers, main hard-drive, gets backed up with my OS. There
are no stray 3rd party DCU/BPLS or sources or garbage files (*.~*) on
this drive. This is just OS drive, 40 GB, 25GB used. Daily defrags.
C:\BORLAND (or Codegear on other machines)
-BP7 (gone now)
-Delphi5
-Delphi7
-RAD Studio
-4.0 (now this one is gone too)
-5.0
-Resource WorkShop
*** all VCL source folders are backed up separately with source control
app (my own source control app) for finding easy changes in sources and
avoid changing them by mistake.
B. 3rd party stuff, goes on my work drive, a 10GB partition, used
4-5GB, fast backups, few times a week. Daily defrags.
P:\LIBS 3rd party and other stuff, sources, no dcu, no garbage
-REGISTRY I save registry keys here, for easy import
-RESURCES I have .res, *dfm and other resources here
-SOURCES
-ABBREVIA
-... tons other 3rd party, only sources, not original installation
which like other folks I install on clean machines and copy over
-VCLD11 modified VCL 2007 units
-VCLD5 modified VCL 5 units
-VCLD7 modified VCL 7 units
P:\PROJECTS main folder for ALL projects
C. temporary files, they go on a "temporary" drive that never gets
backed up. No defrag here. I just delete *.* /s from command com.
R:\LIBS
-5 D5 dcu/dcp
-7 D7 dcu/dcp
-11 D2007 dcu/dcp
-RTL BPLS for all compilers. This gets added to my system Path.
(For this reason, I manually delete all crap that Delphi or 3rd party
installers add to the system path. It would be nice if at least when
updating RAD, it wouldn't change the path, but heck, life is hard)
-------
For this to work, of course I manually edited absolutely all packages
more than 200, probably took me a week, few years ago. But I'm fast
like hell since. At the office I managed to go with the exact same
setup and practically I am 100% sure I get the same binaries no matter
where I compile my apps.
Editing packages went actually a little further: all those that need,
for example ZLIB, are edited and adapted to use my own ZLIB run time
package, which I keep updated (1.2.3 currently). This includes, from
what I remember: DBISAM, FastReport, ReportBuilder, Gnostice PDF and
maybe others. Also, In the past I made sure I was using only one and
the very same GIFImage.pas unit, again all over all my third party.
I think this is all
--
regards,
Lucian
James Miller
"Q Correll" <qcor...@pacNObell.net> wrote in message news:4761baa7$1...@newsgroups.borland.com...
> | Do not install third party components on your 'clean' development
> | machine. Instead, install the components on a 'dirty' machine, ...
>
> Why?
Because you don't know what the installer is going to do to your machine.
It probably will put files all over the placate, like your System32 folder,
and change some registry keys. If you are ok with that, then it's your choice.
Lucian Radulescu
DCPs don't have to be on the PATH.
Lucian
Lucian Radulescu
It is probably a nightmare even to look in those folders...
> bpl and dcp files go to the Delphi's default locations
and, among other things, crams your backups with thousands
of files you don't need because you can recreate
them any time you like
> Be careful if you need to distinguish between debug and release
> versions, in that case it is probably better to have DEBUG and
> RELEASE subdirectory trees for all computer generated junk, kind of
> like Visual Studio does it
Kind of I imagined why you care so much about RELEASE/DEBUG versions :-)
I personally wouldn't care less. Delphi's well known compile speed
makes builds so fast that you don't care if it was 50k or 2 mil lines
of code (probably you get to sip twice from your coffee). Frankly, I
build most of the time because I work on projects that share code and
use conditional symbols.
Lucian
Q Correll
| Because you don't know what the installer is going to do to your
| machine. It probably will put files all over the placate, like your
| System32 folder, and change some registry keys.
I think I may have had some experience with such going-ons. <g>
Thanks.
--
Q
12/14/2007 13:12:58
Andreas Hausladen
> DCPs don't have to be on the PATH.
They must be in the "Delphi Library path" but not in the environment
PATH.
--
Regards,
Andreas Hausladen
Henrick Hellström
>> .dcp in a directory that is already on the PATH - such as the \Bpl
>
> DCPs don't have to be on the PATH.
No, but .bpl files do, and that was my main point. Thanks for the
correction, though.
Bill Bonde
>> but would you like me to create an example with two test packages that
>> contain
>> identically named pas unit files, where these packages can be installed into
>> Delphi 2007 simultaneously?
> yes please I am unable to do so and I would like an example to study.
No problem.
A zip file with a couple of example packages is now in borland.public.attachments.
Andreas Dorn
No, .bpl files of designtime-packages don't have to be in the
system-path. In fact I'd find it very unpractical to work on a package
when using the "single-pile-of-bpl-mud" installation-pattern. (having
different versions of a package around, ...)
Richard Foersom
> While normally I think the c:\Program Files folder is a really good
> concept, there are a few situations where I don't consider it ideal.
> My programming tools is the best example. I install my compilers
> right off the root. For example c:\D5 and c:\D2007.
The program dir concept is OK, name is awful. Why Program *Files*?
Following that foolish idea it should also be "Temp *Files*" and
"Document And Settings *Files*" yuck!
I guess that happend because at Win 95 times they foolishly wanted to
show that you can have spaces and long names, and surely program on its
own would not be long enough.
Also with spaces in filenames setting the Windows path, or writing a
filename in text document or writing programs to scan a command line
has become more messy. You can ofcourse put quotes around the whole
path and file name, but with the path separator as a backslash, then
depending on where you use the quotes path name, the backslash may/may
not act as an escape char. What a mess!
For many Unix programs when used in Windows (CygWin) it is a trouble
with spaces in filenames.
I do follow your idea of short path, but I do not want to install
programs from the C: root, as that quickly gets messy. Rather I install
them as a subdir of C:\Pgm.
> Having my compilers and libraries so near the root makes it far easier
> to do backups, file maintenance, and navigate.
Yes, and for further backup and maintenance, I can recommend to
partition your disk in two drives (perhaps more), a C: for system and
installed programs, and a D: for own files and own development. It
makes it so much easier to know what has to be backed up regurally.
Doei RIF
Andreas Hausladen
> The program dir concept is OK, name is awful. Why Program Files?
The German translators must have known that. They translated it to
"Programme" what means "Programs". :-)
--
Regards,
Andreas Hausladen
Tom Corey
> The program dir concept is OK, name is awful. Why Program Files?
> Following that foolish idea it should also be "Temp *Files*" and
> "Document And Settings *Files*" yuck!
100% agreement!
Rudy Velthuis [TeamB]
> Tom Corey wrote:
>
> > While normally I think the c:\Program Files folder is a really good
> > concept, there are a few situations where I don't consider it ideal.
> > My programming tools is the best example. I install my compilers
> > right off the root. For example c:\D5 and c:\D2007.
>
> The program dir concept is OK, name is awful. Why Program Files?
Because "Programs" alone is a bit ambiguous, and usually, also the
supporting files for a program are stored there.
--
Rudy Velthuis [TeamB] http://www.teamb.com
"A coward is a hero with a wife, kids, and a mortgage."
-- Marvin Kitman.
Henrick Hellström
> No, .bpl files of designtime-packages don't have to be in the
> system-path.
What needs to be on the path are any .bpl files that are required by any
installed designe time package. Hence, if you follow the recommended
procedure and separate your component code into one design time package
and one run time package, the latter needs to be on the system path.
In pre-BDS versions you might not have noticed this if you installed the
run time package as well, and installed it prior to the design time
package. With the late package loading featured in BDS/RAD Studio (which
solves a lot of other issues and is a good thing from other povs) this
approach doesn't work any more.
Chris Morgan
> with spaces in filenames.
Unix had long filenames and filenames containing spaces long before
windows ever did.
Its a bug if programs cannot deal with spaces in filenames - a
common bug, but still a bug.
Cheers,
Chris
Chris Morgan
> I've just completed installing RAD Studio 2007, and am about to begin the
> process of migrating from Delphi 5.
>
> First up is installation of third party components. In my previous D5
> installation, my third party components tended to be scattered all over the
> place, resulting in a very disorganized setup. This result was mostly due to
> my being a new Delphi user when I first started installing the third party
> components and not being exactly sure what was going on.
>
> I would like to try to keep my installation of third party components more
> organized with D2007. Is there a particular strategy that you all employ as
> far as where components are stored and such?
>
> Any and all comments appreciated.
Personally, I avoid 3rd party components unless absolutely necessary.
This makes upgrading Delphi much easier!
For our apps, we do not use 3rd-party GUI components.
We decided we needed to use a 3rd party solution to use oracle (ODAC),
and to support DBF files without the BDE (Topaz - not brilliant, but
OK), but other than that, we use Delphi out of the box. There is
plenty of scope for customising the GUI using just the components
supplied with
Delphi. And we have extended quite a lot of them using
non-visual derived classes.
cheers,
Chris
Richard Foersom
> 100% agreement!
At my home system I have completely changed "Program Files" into Pgm.
You can do that on a fresh Win 2000 install, however it require quite
some work to fix up the registry. Also "Common Files" is changed to
just common, and "Document and Settings" is DocSet.
Due to the work involved I will not recommend to do all this, unless
you are really annoyed with these MS dir names - like me ;-).
Doei RIF
Richard Foersom
> Because "Programs" alone is a bit ambiguous, and usually, also the
> supporting files for a program are stored there.
Oh-really? Then it definately made it all clear by adding the word
files.
Alright, so they should have called the dir: "Programs, ini,
uninstallers, cache and other miscellanous files". ;-)
Doei RIF
Richard Foersom
> The German translators must have known that. They translated it to
> "Programme" what means "Programs". :-)
You are right, I recall that from a batch file of a DE client ;-).
Doei RIF
Zoren Lendry
> Due to the work involved I will not recommend to do all this, unless
> you are really annoyed with these MS dir names - like me ;-).
A man after my own heart! I haven't done it because of the trouble. Just
because you can have a long name with spaces, doesn't mean that you
should. Then other vendors start following MS's example, and you end up
with Environment paths that won't fit in the ridiculously restricted
2048 limit that MS still has, not to mention the ridiculous dialog box
they give you to edit this value. I'd better stop now, or I'll never
make it home today.
Loren
Arthur Hoornweg
> I personally install all my components under X:\Program
> Files\CodeGear\Components (rather than C:\Program Files).
I use partition "D:" for sourcecode and components because it
makes backups easier.
"D:\Delphi" is the root path for all components and my own projects
land under "D:\Delphi\Arthur".
--
Arthur Hoornweg
(In order to reply per e-mail, please just remove the ".net"
from my e-mail address. Leave the rest of the address intact
including the "antispam" part. I had to take this measure to
counteract unsollicited mail.)