How can I share code or create a static library in Delphi ?
Timothy Madden
I have two related projects in my project group (Delphi 10, BDS 2006)
that share a number of files, in a tree like this:
ProjectGroup
- Common
- Utils.pas
- ZLib.pas
- Components.pas
- GraphicApp.exe
- MainApp.pas
- GUI.pas
- ConsoleApp.exe
- MainConsole.pas
- CLI.pas
Now GraphicApp and ConsoleApp projects both use files in project
Common.
I would like Common to be some sort of a library project, library that
GraphicApp
and ConsoleApp would depend on.
Does Delphi have native libraries ?
Or can I set it somehow to output even a C++ like .lib file,
and then use it in my other projects ? But I would still like to
have types and forms in my library, and I am afraid this is
hard to do with a .lib file
I tried to create project Common as a package project, but then it
would create
a run-time file Common.bpl which works kind of like a .dll, only in a
Borlad - specific
format. Meaning it has to stay near the executable, which my clients
might not like,
or be included in the system's PATH variable.
I do not want any dll or dynamic libraries, I only have a number of
source files
that I want to use in both projects and what I need is a static
library or some object
files of some kind.
Can I create a package like a static library, that would be linked in
at compile time ?
Or can I have some kind of project that just compiles the .pas files
to .dcu files and
then puts them somewhere, where I can use them in the other projects ?
Every kind of project I saw wants to output some sort of executable,
different than the
.dcu files.
Kind regards,
Timothy Madden
Timothy Madden
at compile time ? Does Delphi have a native static library format ?
Peter Below (TeamB)
> I do not want any dll or dynamic libraries, I only have a number of
> source files that I want to use in both projects and what I need is
> a static library or some object files of some kind.
Delphi does not support that. The closest equialent to obj files are
dcus, if the compiler can find those on a common folder (one on the
library path, for example) it does not need access to the source files.
--
Peter Below (TeamB)
Don't be a vampire (http://slash7.com/pages/vampires),
use the newsgroup archives :
http://www.tamaracka.com/search.htm
http://groups.google.com
Raul
If all you require is to have a common library of functions then why not
just include the common files in both (all) projects ?
It works just fine.
Raul
"Timothy Madden" <termin...@gmail.com> wrote in message
news:Lucy121733721...@jupiter.eamobile.ad.ea.com...
Krisztian Pinter
<termin...@gmail.com> wrote:
> I would like Common to be some sort of a library project, library that
> GraphicApp and ConsoleApp would depend on.
really, what would be the benefit over simply reusing the units?
Marc Rohloff [TeamB]
> I have two related projects in my project group (Delphi 10, BDS 2006)
> that share a number of files, in a tree like this:
Why not just include the 'Common' folder in the search path for both
projects? You could also look at the WEAKPACKAGEUNIT directive.
You can also use project groups so that you can easily browse all the
source files.
--
Marc Rohloff [TeamB]
marc -at- marc rohloff -dot- com
Timothy Madden
How do I create the units in project Common, but only use them in other projects ?
What type of project Common has to be, to compile the units but not use them ?
I thought about same sort of a library project, but Delphi seems to only understand
.dll or .bpl files as libraries, and I want a static library.
Timothy Madden
nos...@example.com
>
>If all you require is to have a common library of functions then why not
>just include the common files in both (all) projects ?
>
>It works just fine.
I would have to refer in my projects to source files outside the project.
I think there are better ways.
And then this is what libraries are for, share code instead of including
it everywhere.
Thank you,
Timothy Madden
nos...@example.com
>Timothy Madden wrote:
>
>> I do not want any dll or dynamic libraries, I only have a number of
>> source files that I want to use in both projects and what I need is
>> a static library or some object files of some kind.
>
>Delphi does not support that. The closest equialent to obj files are
>dcus, if the compiler can find those on a common folder (one on the
>library path, for example) it does not need access to the source files.
Is there a reason for this ?
Can I build the .dcus without using them in the same project ?
The ideea is to use .dcu from project Common in projects GUIApp and CosoleApp
Except that project Common does not use them.
Thank you,
Timothy Madden
nos...@example.com
>On 29 Jul 2008 13:13:37 GMT, Timothy Madden wrote:
>
>> I have two related projects in my project group (Delphi 10, BDS 2006)
>> that share a number of files, in a tree like this:
>
>Why not just include the 'Common' folder in the search path for both
>projects? You could also look at the WEAKPACKAGEUNIT directive.
>
>You can also use project groups so that you can easily browse all the
>source files.
I use project groups. I have the projects Common, GUIApp and ConsoleApp in
my group.
What search path ?
The point is project Common only builds a library, or the dcu files, without
using or needing them, which I do not know how to do.
Timothy Madden
Descartes AT -REMOVE-THIS- DOT
<nos...@example.com> wrote:
>
> I would have to refer in my projects to source files outside the
> project.
Not to source (.pas) files. You would only have to indicate them in
the uses clause once they are compiled to dcu's.
Best regards
Descartes
Krisztian Pinter
<termin...@gmail.com> wrote:
> How do I create the units in project Common, but only use them in other
> projects ?
there would be no project Common. only create a directory, put the source
codes
there, and use them in your GUI and console projects. by using, i mean
adding
them to the project source. you can also add the common directory to the
search
path, but i don't recommend it. i recommend always adding all the units to
the
project.
Marc Rohloff [TeamB]
> How do I create the units in project Common, but only use them in other projects ?
> What type of project Common has to be, to compile the units but not use them ?
It doesn't really matter since the other projects will access the
unit's pas and dcu files and not the output of the project. You don't
even need an extra project for 'Common' unless you want to have your
common files appear in a separate 'project' in your project group. In
this case the project is just a dummy project.
> What search path ?
Project Options/Directories, or the equivalent in the global options
dialog.
Timothy Madden
The point is to use only the .dcu files in the other projects. Otherwise
one of the projects would include source files outside its project
folder, which I think is not nice.
That dummy project that would compile the .pas files to .dcu files, as
much as it 'doesn't really matter', is my problem, because Delphi has no
project type to just compile units and then give me the .dcu files and
do nothing else with them.
I guess I will have to let the dummy project be a package project, as
it is now, and then add the .dcu files directory to the other projects'
library path, I guess, as Peter Below suggested.
It is not exactly the solution I wanted, but things with Delphi look
like this is the best I can do. I wish Delphi had native static libraries.
Thank you,
Timothy Madden
Maël Hörz
> Otherwise one of the projects would include source files outside its
> project folder, which I think is not nice.
automatically, else the DCU is used. Both simple and efficient.
What is the problem of having the source in different folders? And what
is the advantage of a lib-file? It will still be in a different folder,
except if you copy it.
Really, it is not necessary in Delphi. Including (using) a unit is as I
said both easy and efficient. If one of the common units code changes it
will automatically be recompiled (when you compile a project that uses
it), if no change was done the DCU is used directly. That is really
simple and clean. LIBs are just not necessary and will not speed up
compiling or clean up your project in any way (your includes/uses will
still look the same).
If you absolutely want to build the common files independently, you can
use a similar technique that is used for the RTL files. See
Source\Rtl\makefile. But it is not really comfortable.
Alternatively, make a runtime package that includes your common units.
You can compile that independently. But be sure that when you build your
EXE the runtime-packages option is *dis*abled (project|options).
In the end, still DCUs will be used the same way, except that you would
be able to build your common units from on central point.
Iain Macmillan
<ma...@nospam.marcrohloff.com> wrote:
> On 29 Jul 2008 14:57:48 GMT, Timothy Madden wrote:
>
>> How do I create the units in project Common, but only use them in other
> projects ?
>> What type of project Common has to be, to compile the units but not use them
?
>
> It doesn't really matter since the other projects will access the
> unit's pas and dcu files and not the output of the project. You don't
> even need an extra project for 'Common' unless you want to have your
> common files appear in a separate 'project' in your project group. In
> this case the project is just a dummy project.
All true.
But the answer to 'how to compile units standalone, other than "using" them
in a project?' is imho, use command-line compiler DCC32.exe naming the .pas
file as parameter.
If he's used to the lib utility this approach should be familiar to him!
Krisztian Pinter
<termin...@gmail.com> wrote:
> one of the projects would include source files outside its project
> folder, which I think is not nice.
both of them, if you want it manageable. there is no problem with this
design. the library would be also outside the project folder, so what
difference does it make? lib = bunch of source files
design your directory hierarchy logically.
ProjectSource
Common
GUIVersion
CmdLnVersion
you can go even deeper. we for example have multiple completely different
projects, and they still share a few utility units. string manipulation,
and such things are in them. so our hierarchy looks like
Sources
General
SomeProject
Common
SomeVariant
OtherVariant
OtherProject
the project SomeVariant uses SomeProject\Common and Sources\General too.
you stuck with some routine, which is not a good way to start using a new
environment. separate compilation of the common part is simply unnecessary.
the compiler will compile them as needed.
Peter Below (TeamB)
> In: <xn0ft9bk...@newsgroups.borland.com>, "Peter Below (TeamB)"
> <no...@nomail.please> wrote:
> > Timothy Madden wrote:
> > Delphi does not support that. The closest equialent to obj files are
> > dcus, if the compiler can find those on a common folder (one on the
> > library path, for example) it does not need access to the source
> > files.
>
> Is there a reason for this ?
It's simply not needed. The compiler is so fast that recompiling some
units you add to a project takes no significant time. The only reason
to use precompiled LIBs in C/C++ is because the compiler is so damned
slow <g>.
> Can I build the .dcus without using them in the same project ?
You could add them to a dummy project that only contains these shared
units and nothing else. Build that to produce the DCUs.
> The ideea is to use .dcu from project Common in projects GUIApp and
> CosoleApp Except that project Common does not use them.
I really do not see your point. If a project requires a unit simply add
it to the project (or directly to a Uses clause if the path to the dcus
is on the library search path) and build the project. Don't try to
force your view of code organisation (which comes from another
development environment) onto Delphi, the IDE is perfectly able to
manage without your interference, you know <g>.
nos...@example.com
I only wanted to find our, from the people who know, if what I see is true.
Thank you,
Timothy Madden
Marc Rohloff [TeamB]
> But the answer to 'how to compile units standalone, other than "using" them
> in a project?' is imho, use command-line compiler DCC32.exe naming the .pas
> file as parameter.
You could, but I don't see the point since, when you compile either of
the projects, the compiler will compile them for you.
Iain Macmillan
In article <wh0k2j7zgqs1$.d...@dlg.marcrohloff.com>, "Marc Rohloff [TeamB]"
<ma...@nospam.marcrohloff.com> wrote:
> On Wed, 30 Jul 2008 02:46:42 +0100, Iain Macmillan wrote:
>
>> But the answer to 'how to compile units standalone, other than "using" them
>> in a project?' is imho, use command-line compiler DCC32.exe naming the .pas
>> file as parameter.
>
> You could, but I don't see the point since, when you compile either of
> the projects, the compiler will compile them for you.
Indeed.
The point might be, that I have written a bunch of library routines and now
I want to see if they actually compile!
(But, granted, in this scenario the next step ought to be to call them in a
test environment, presumably a project, and look for execution errors).
Maël Hörz
> The point might be, that I have written a bunch of library routines and now
> I want to see if they actually compile!
> (But, granted, in this scenario the next step ought to be to call them in a
> test environment, presumably a project, and look for execution errors).
package (using a makefile or DCC directly is too much hassle). You could
compile it to find syntax errors and use the units in your project as
usual (make sure run-time package option is disabled for your
EXE-project if you don't want to distribute the BPL-file, i.e. you want
to have a statically linked EXE).
In fact I have a similar setup since I have my own components which are
in a design-time package, and since they use common units, those common
units are also (and for technical reasons have to be) in a package.