Standard Units Library and Version Control
Thomas J. Theobald (Borland/Inprise)
each version of Delphi or each project you work with? If you want to
automate this, you could extract the registry setting as a .reg file, and
merge it before or after the install of that particular version of Delphi.
T
"Kristofer Skaug" <kris...@skaug.demon.nl> wrote in message
news:3a23061d$2_2@dnews...
> Hi,
>
> I am trying to set up a standard library of standard Delphi components,
> classes and utility units on our company's network server. This is
> presenting some serious headaches: Since Delphi units are "used" only by
> unit name (and not with a full path name, as in C/C++ #include
statements),
> how do I go about managing different versions of a unit? I'd be grateful
to
> hear how other people have solved such problems.
>
> Kristofer
>
>
>
>
Kristofer Skaug
Russell Smith
control and I have not yet figured out a strategy on how to deal with custom
written components in a team environment.
With standard units, the users all link to a common network path. This is
set as the local path for the source files in VSS.
Components are a new kettle of fish somehow. The users need to know when to
rebuild their component libraries. Also components do not lend themselves to
being installed on a network drive so well.
If anybody has any strategies for this I would appreciate any suggestions
Cheers,
Russell Smith
pnichols
drive/directory location?
Usually we divide our components and packages as follows:
Dev (Development work)
---Comps (Components)
--- Packages
--- dcufiles
----pasfiles
--- docs
--- Apps
--- exes
--- dcufiles
--- pasfiles
--- docs
--- Dlls [not packages]
--- dlls
--dcufiles
-- pasfiles
--docs
Test --> to be tested and in Alpha
Repeat above sub structure
Beta --->
Repeat above structure
Production ----> Current Distributed Version
Repeat above structure
Archive --> Previous Versions
Versions
Repeat above Structure
Usr this structure for all Warehousing, including Java and C++. Of course
the dcu and Pas files change, but same type of version control.
"Kristofer Skaug" <kris...@skaug.demon.nl> wrote in message
news:3a23061d$2_2@dnews...
Kristofer Skaug
news:3a236122$1_1@dnews...
> what about a standard packaging name for your components and a
standard
> drive/directory location?
We don't have so many VCL components (yet), mainly I am concerned
about classes and units (i.e. stuff you don't really need to package
for the pallette but would like to re-use anyway in various projects).
> Usually we divide our components and packages as follows:
>
> Dev (Development work)
> ---Comps (Components)
....
Do you keep utility units and classes in here as well?
> --- Apps
> --- exes
> --- dcufiles
> --- pasfiles
> --- docs
Where do your project files go? (.dprs) => seems odd to keep exes,
dcus, source and documentation for N apps distributed over 4 base
folders like this... what's the rationale? Is the root folder of your
described structure something like "\Standard", i.e. cross-project
software only? I'm confused by the "Apps" and "Dlls" in your
structure. Anyway, thanks for the input!
Kristofer
Sebastian Moleski
> Hi,
>
> I am trying to set up a standard library of standard Delphi components,
> classes and utility units on our company's network server. This is
> presenting some serious headaches: Since Delphi units are "used" only by
> unit name (and not with a full path name, as in C/C++ #include
statements),
the exact name and location of that unit file:
uses
Test in '..\test\test.pas';
sm
Kristofer Skaug
news:8vvsub$1u...@bornews.inprise.com...
.... Remember that uses allows an 'in' clause specifying
> the exact name and location of that unit file:
>
> uses
> Test in '..\test\test.pas';
>
Err, thanks Sebastian! Always been looking at that in the .dpr files
but never thought it would be useable in other uses clauses as well?
This would help to clarify locally which exact version of a unit is
required, however of course you can't add a unit of the same name
(with different source paths) to a project twice. I was toying with
the idea of renaming each unit with an extension reflecting its
version number, e.g.
StdFunc_01_13_12.pas
StdFunc_01_14_00.pas
However, you do get in serious trouble with the IDE Editor tab width
this way.... (By the way, I hate long filenames; they tend to result
in names which are long and clumsy and not a bit more explanatory than
a well chosen 8.3 filename... people come up with weird spellings and
foggy descriptions, and everyone else has to suffer by typing all that
into their uses clauses... therefore I would like to stay in 8.3 for
Delphi source if at all possible).
Kristofer
Deepak Shenoy
It's better to use relative paths in the DPR file (like Sebastian suggested)
and add all the components source files into the project. Maintain a
hierarchy and in the project options file (.DOF?) , store the relative paths
of all directories in the search path. I have a structure like so:
Project
bin
dcu
Components
...
Source
Data
Utilities
...
Backup
The bin directory gets all the BPL, EXE and DLL files. Others should be self
explanatory.
To make sure that everyone gets the latest design time properties you might
want to maintain a copy of the BPL in the version control software.
I would suggest that you ask all programmers to maintain local copies of
even "shared" files such as libraries, components etc. It's easier to
maintain, change etc. You could also write a utility which will check for
new components/files and recompile any components locally, using DCC (but
that might be overkill)
--
Deepak Shenoy
Agni Software
http://www.agnisoft.com
GenJerDan
> This would help to clarify locally which exact version of a unit is
> required, however of course you can't add a unit of the same name
> (with different source paths) to a project twice.
like:
unit Wrap1;
interface
uses Test in '..\test\test.pas';
implementaion
end.
unit Wrap2;
interface
uses Test in '..\taste\test.pas';
implementation
end.
Daniel J. Wojcik
http://www.genjerdan.com/bfpindex.html
I remember a man who
Jumped out from a window over the bay
(There was hardly a raised eyebrow)
The coroner told me,
This kind of thing happens every day.
You see, from the Pagoda, the world is so tiny.
Kristofer Skaug
news:07D00B1C...@www.200mmc.21tsc.army.mil...
> Could you "wrap" them in other units, and use *those* units?
>
> like:
>
> unit Wrap1;
> interface
> uses Test in '..\test\test.pas';
> implementaion
> end.
Interesting idea...
Haven't tried that, but how would it work?
I suppose you'd need to have the interface signature of Test.pas
copied over to unit Wrap1?
Kristofer
GenJerDan
> Haven't tried that, but how would it work?
> I suppose you'd need to have the interface signature of Test.pas
> copied over to unit Wrap1?
units...just popped into my head to try it that way.
And it would be a real pain to use something like that when you
need the Form from the unit, too, and not just code.
Probably much easier just renaming one of them. :>)
--
Daniel J. Wojcik
"Power corrupts, and absolute power is actually pretty neat."