How to compile DPKs for release?

51 views
Skip to first unread message

Stephan

unread,
Sep 3, 2004, 8:50:59 AM9/3/04
to

Hi guys,

when producing release versions of our packages, I of course rely on
dcc32.exe (D5 - D7) to do this (and, in my case, a few dozen Makefiles).

But how do I make sure that the command line parameters passed to
dcc32.exe are really the ones active for the compilation process? I
noticed that the DPK files contain directives like {$DEBUGINFO ON},
which is where the IDE stores the project options (quite a concept!).

How do I override these directives on the command line?

Thanks in advance for any hints,

Stephan

Nick Hodges [TeamB]

unread,
Sep 3, 2004, 9:46:14 AM9/3/04
to
Stephan wrote:

> How do I override these directives on the command line?

Use the CFG file that accompanies the command line compiler. DCC32
will use whatever settings are found there.

--
Nick Hodges -- TeamB
Lemanix Corporation -- http://www.lemanix.com
Read my Blog -- http://www.lemanix.com/nick

Allen Bauer

unread,
Sep 3, 2004, 11:21:44 AM9/3/04
to
> when producing release versions of our packages, I of course rely on
> dcc32.exe (D5 - D7) to do this (and, in my case, a few dozen Makefiles).
>
> But how do I make sure that the command line parameters passed to
> dcc32.exe are really the ones active for the compilation process? I
> noticed that the DPK files contain directives like {$DEBUGINFO ON},
> which is where the IDE stores the project options (quite a concept!).

The IDE supports a very little know feature where you can continue to
control these options while in the IDE, yet allow the command-line be able
to also control the options. In a package file, all the options listed
there are propagated to all the contained units. This is different than a
normal .dpr program/library file. In order to do this, all you need to do
is replace the '$' with a ' ' (that's a <space>). Then when you open the
dpk in the IDE, you can toggle those options as much as you like, but when
you compile on the command-line, you can still control them.

This is how we build all our packages for the product itself. All of the
Borland built packages have DEBUGINFO, STACKFRAMES, ASSERTIONS,
OPTIMIZATION, LOCALSYMBOLS setup this way because like you, we wan't to be
able to control those options from the command-line. The developers will
typically do a complete "debug" build, whereas the integration team will
not.

$DEFINES will sort of work the same way, in that if you replace the '$' with
a ' ', the IDE will still recognize the defines and apply them, but any
other modifications to the dpk source will re-insert the '$' character.

--
Allen Bauer
Delphi/C#Builder Principal Architect
Borland Software Corporation.
http://blogs.borland.com/abauer


Ray A.

unread,
Sep 3, 2004, 7:19:40 PM9/3/04
to
Stephan wrote:

What I do is run a simple program I created that rewrites dpk's, cfg's,
dof's, and rc's, based on predefined templates, with the desired
settings. Then it creates a batch file and compiles the resource files
and packages.

When the quality control manager gets new packages or updated packages
from the programmers, she just runs the program to prepare the files
for what she needs (for example: removing debugging and stamping file
versions) before release.

Also, all release packages and programs are compiled on a single
production computer to ensure they are all built with the same
libraries.

Hope this helps.

Ray A.

Ottar Smidesang Holstad

unread,
Sep 4, 2004, 2:05:33 PM9/4/04
to
If you have to do compiles for release often, FinalBuilder (
http://www.atozedsoftware.com/finalbuilder/ ) is well worth buying. In
FinalBuilder there is a compiler-options dialog very similar to the one in
Delphi which is saved in the FinalBuilder project-file. These options are
then used to build the commandline FinalBuilder is issuing to do the
compile.


Stephan

unread,
Sep 6, 2004, 5:53:50 AM9/6/04
to

Hi Nick,

thanks for your reply.

> Use the CFG file that accompanies the command line compiler. DCC32
> will use whatever settings are found there.
>

Are you sure the settings in the dcc32.cfg file (or on the command line)
override the directives in the .dpk file?

Stephan

Stephan

unread,
Sep 6, 2004, 6:00:28 AM9/6/04
to

Hi Allen,

thanks a lot for your reply.

> The IDE supports a very little know feature where you can continue to
> control these options while in the IDE, yet allow the command-line be able
> to also control the options. In a package file, all the options listed
> there are propagated to all the contained units. This is different than a
> normal .dpr program/library file. In order to do this, all you need to do
> is replace the '$' with a ' ' (that's a <space>).

Wow, I had no idea... You say that this feature is "very little known",
I guess this means it's documented *somewhere*. Would you happen to
remember where?

>
> This is how we build all our packages for the product itself. All of the
> Borland built packages have DEBUGINFO, STACKFRAMES, ASSERTIONS,
> OPTIMIZATION, LOCALSYMBOLS setup this way because like you, we wan't to be
> able to control those options from the command-line. The developers will
> typically do a complete "debug" build, whereas the integration team will
> not.

I tried it, works nicely, thanks a lot for the tip!

Btw, I find that such information, which is relevant to developers who
really produce code for professional use, very hard to find. I believe
there are a lot of such tips and techniques out there, but Borland does
not seem to provide them in an organized fashion anywhere. Are there any
good resources out there for people like us, who Borland seems to
completely overlook?

All the best,

Stephan

Stephan

unread,
Sep 6, 2004, 6:09:13 AM9/6/04
to

Ray,

thanks for your post.

> What I do is run a simple program I created that rewrites dpk's, cfg's,
> dof's, and rc's, based on predefined templates, with the desired
> settings. Then it creates a batch file and compiles the resource files
> and packages.

Actually, I tried a simplified version of this. Through the Makefile, a
file mycomp_final.dpk is created from the regular mycomp.dpk, which has
different directives. But the problem was that dcc32 does not even seem
have an option to name the resulting files (BPLs, DCPs, etc.)
independent of the input file name... So you end up having to fix lots
of follow-up effects too.

I guess your approach with real templates for all files involved
resolves such issues thoroughly.

I have to say that for a command-line compiler, dcc32.exe (I'm using it
in Delphi versions 5 - 7) really offers only the most basic options,
it's quite disappointing considering we're at product version 7!

All the best,

Stephan

Stephan

unread,
Sep 6, 2004, 6:17:15 AM9/6/04
to

Hi Ottar,

> If you have to do compiles for release often, FinalBuilder (
> http://www.atozedsoftware.com/finalbuilder/ ) is well worth buying.

actually, I came across FinalBuilder some time ago too, it looks really
useful.

The price seem to be a bit steep though, but maybe I give the evaluation
version a try at some point...

All the best,

Stephan

Vincent Parrett (Atozed Software)

unread,
Sep 6, 2004, 6:48:16 AM9/6/04
to
"Allen Bauer" <aba...@spicedham.borland.com> wrote in message
news:41388c09$1...@newsgroups.borland.com...

> The IDE supports a very little know feature where you can continue to
> control these options while in the IDE, yet allow the command-line be able
> to also control the options.

Why isn't this used as the default when creating packages? I just added
support for updating the settings in a dpk file to FinalBuilder a few weeks
ago, but of course this little nugget breaks my parser :) Is it documented
anywhere (I haven't managed to find anything about it in the help).

--
Regards

Vincent Parrett
Atozed Software http://www.atozedsoftware.com
My blog : http://blogs.atozed.com/vincent
----------------------------------------
Automate your Build Process with FinalBuilder


Anders Isaksson

unread,
Sep 6, 2004, 8:02:28 AM9/6/04
to
On Mon, 06 Sep 2004 12:17:15 +0200, Stephan
<cyber.mail7...@xoxy.net> wrote:

>> http://www.atozedsoftware.com/finalbuilder/


>
>The price seem to be a bit steep though,

Depends on how you count.

A: How much value do you put on one hour of work?
B: How many hours will FinalBuilder save you during it's lifetime?

if (A*B) > Price(FinalBuilder) then
// It's worth it, because you actually *save* money


--
Anders Isaksson, Sweden
BlockCAD: http://w1.161.telia.com/~u16122508/proglego.htm
Gallery: http://w1.161.telia.com/~u16122508/gallery/index.htm

Nick Hodges [TeamB]

unread,
Sep 6, 2004, 11:42:36 AM9/6/04
to
Stephan wrote:

> Are you sure the settings in the dcc32.cfg file (or on the command
> line) override the directives in the .dpk file?

Yes -- that's what its for.

Derek Davidson

unread,
Sep 6, 2004, 11:59:34 AM9/6/04
to
Anders Isaksson wrote:

> if (A*B) > Price(FinalBuilder) then
> // It's worth it, because you actually save money

I find these sort of equations very neat but they avoid some simple
truisms as regards programming.

Joel ( www.joelonsoftware.com ) makes the point very well. Programmers
tend to work in burst mode. We have periods of frenetic (programming)
activity liberally interspersed with 'cool down' (read e-mail, performs
some menial task) periods. During these cool down periods, you can
perform those boring, but necessary, build tasks.

If you were to look at your working day and have the clock running for
those periods that you are *really* working, then average that over a
longer period of time (say a few months), I'd say that we may all be
surprised how little *actual* work we do.

Of course, I'm using the original authors post to piggy back off and
make a more general point. There are worse offenders. My 'favourite'
are the IDE tools that reduce your keystrokes and thus save you time.
Cue amazing CBA. Hmmm.

There are other considerations too. For example, ask my bank manager
what the value of a worked hour is and he'll tell you "Nothing. Show me
the money". Ask him what [price of product A] is worth and he'll tell
you to the penny.

Now, all this said, I find tools like FinalBuilder very valuable and I
do use them. I just don't find the simplified CBA type of argument at
all compelling (and, maybe more importantly, neither does my Bank
Manager <g> ).

--
Derek Davidson
http://www.ebsms.com
Send SMS Text messages from your PC. For FREE!

Vincent Parrett (Atozed Software)

unread,
Sep 6, 2004, 6:28:19 PM9/6/04
to
"Stephan" <cyber.mail7...@xoxy.net> wrote in message
news:413c3844$1...@newsgroups.borland.com...

> actually, I came across FinalBuilder some time ago too, it looks really
> useful.
>
> The price seem to be a bit steep though, but maybe I give the evaluation
> version a try at some point...

Unfortunately we can't please everyone when it comes to price, however in a
recent survey we conducted with our customers, 85% said the price was "about
right". Pricing of products is a very difficult thing to do, Eric Sink from
sourcegear has some interesting things to say about this on his blog :

http://software.ericsink.com/bos/Product_Pricing.html

Anders Isaksson

unread,
Sep 7, 2004, 2:42:29 AM9/7/04
to
On 6 Sep 2004 08:59:34 -0700, "Derek Davidson"
<derek.d...@gmail.com> wrote:

> I find these sort of equations very neat but they avoid some simple
> truisms as regards programming.

I mostly agree.

> Joel ( www.joelonsoftware.com ) makes the point very well. Programmers
> tend to work in burst mode. We have periods of frenetic (programming)
> activity liberally interspersed with 'cool down' (read e-mail, performs
> some menial task) periods. During these cool down periods, you can
> perform those boring, but necessary, build tasks.

What I was trying to say was that FB would probably save you the need
for a lot of frenzy, namely getting command line compilation working as
you expect, reliably. When you finally have worked out the batch files,
or scripting progams, or whatever, that you need for dcc32, you don't
need to buy FB any longer. OTOH, if you get it from the beginning, you
can use your frenzy for some other purpose.

> There are worse offenders. My 'favourite' are the IDE tools that
> reduce your keystrokes and thus save you time. Cue amazing CBA. Hmmm.

Sorry, I don't understand what you are saying here (Cultural frame of
reference?).

>There are other considerations too. For example, ask my bank manager
>what the value of a worked hour is and he'll tell you "Nothing. Show me
>the money". Ask him what [price of product A] is worth and he'll tell
>you to the penny.

Ask him: Should I spend the next month developing something that already
exists (earning nothing during the time), or should I buy the product,
and start working on something else (earning something) tomorrow.

Always presuming there *is* other work waiting to be done, of course.
Otherwise you might as well (re-)develop something just for the learning
experience.

Derek Davidson

unread,
Sep 7, 2004, 2:53:58 AM9/7/04
to
Anders Isaksson wrote:

> > There are worse offenders. My 'favourite' are the IDE tools that
> > reduce your keystrokes and thus save you time. Cue amazing CBA.
> > Hmmm.
>
> Sorry, I don't understand what you are saying here (Cultural frame of
> reference?).

I was trying to show that my main form of reference for the comment was
not your post alone. That there are worse offenders out there that draw
the 'cost benefit analysis (CBA)' of time savings produced by using
their tool.

Stephan

unread,
Sep 7, 2004, 4:01:27 AM9/7/04
to

Hi Nick,

>>Are you sure the settings in the dcc32.cfg file (or on the command
>>line) override the directives in the .dpk file?
>
>
> Yes -- that's what its for.

hum, I have tried all kinds of scenarios in the past hour, if I have the
line

{$DEBUGINFO ON}

in the file projectname.dpk, I can't seem to override it with the option
-$D- in the dcc32.cfg file or on the dcc32.exe command line.

Btw., I check this by having the lines

{$IFOPT D+}
{$Message Warn 'DEBUG INFO IS ON!'}
{$ENDIF}

in one of my units.

In the D6 help under "Compiler directives", I read:

"Compiler directives in the source code always override the command-line
compiler directives and the IDE project options."


Another related thing:

The IDE obviously generates a file projectname.cfg, which then of course
has the IDE's "development" settings I don't want for release builds.
What's the use of setting up a dcc32.cfg in my project directory if
dcc32.exe always reads the configuration settings in projectname.cfg too?

From the D6 help:

"The compiler searches for a dcc32.cfg in the compiler executable
directory, then for dcc32.cfg in thecurrent directory, and then finally
for projectname.cfg in the project directory."

So, trying to sum it up, compiler settings can come from
- the command line
- the dcc32.cfg file in the compiler executable directory
- the dcc32.cfg file in the current directory
- the projectname.cfg in the project directory
- compiler directives in the projectname.dpk file
- compiler directives in the unit source files

Plus some of these files are automatically created and updated by the
IDE with the IDE settings from projectname.dof. All of this together
makes it really hard to figure out where your currectly active options
come from.

Frankly, this system doesn't look to be designed by one who had the
needs of professional software developers in mind who need to switch
easily between development and release versions. It looks like dcc32.exe
doesn't even have an option to list the currently active options!

All the best,

Stephan

Stephan

unread,
Sep 7, 2004, 4:20:25 AM9/7/04
to

Hi Vincent,

thanks for your reply.

>>The price seem to be a bit steep though, but maybe I give the evaluation
>>version a try at some point...
>
>
> Unfortunately we can't please everyone when it comes to price, however in a
> recent survey we conducted with our customers, 85% said the price was "about
> right".

Maybe I should clarify that a little: I have looked at the features of
FB before, they are really impressive and no doubt well worth the money,
since you support such a wide range of tools.

The thing is, I only need to call the various Delphi compilers (D5 -
D7), Doc-O-Matic, plus a few scripts of my own (Perl). Normally, that's
nothing you can't do perfectly fine with a Makefile, especially if
you're using cygwin anyway.

What I find *really disturbing* (and let me be perfectly clear, this has
*nothing* to do with you or FB, but with Borland), is that in order to
perform such seemingly simple tasks as compiling my packages for release
from the command line, I might benefit from buying a $300 add-on *just*
to keep the rules and conditions straight under which my source is compiled.

I've been working with Borland tools since Turbo Pascal V3, I can't
believe that after all these years and many product versions later, the
simple question of how to set up your environment in order to

- compile my source for development in the IDE with some
switches/directives "on", and

- compiling my source for release from the command line with some
switches/directives "off"

is more than a 10 minute browse in the docs and a 30 minute practical
implementation test of it away.

All the best,

Stephan

Vincent Parrett (Atozed Software)

unread,
Sep 7, 2004, 9:33:51 AM9/7/04
to
"Stephan" <cyber.mail7...@xoxy.net> wrote in message
news:413d69f0$1...@newsgroups.borland.com...

> hum, I have tried all kinds of scenarios in the past hour, if I have the
> line
>
> {$DEBUGINFO ON}
>
> in the file projectname.dpk, I can't seem to override it with the option
> -$D- in the dcc32.cfg file or on the dcc32.exe command line.

You cannot override most settings in the dpk from the command line or cfg
file. I just added support in the lastest build of finalbuilder to update
the the dpk with the required settings because of this. It's a pity these
settings are stored in the source, as it really goes against the grain to
modify the source to change compiler settings, it's something we've tried to
avoid doing with finalbuilder for many years, only relenting recently due to
customer demand.

BTW, the way finalbuilder deals with the compiler settings is to generate a
projectname.cfg file for use by the command line compiler. It never uses the
cfg generated by the IDE, and in fact in some cases (with older versions of
delphi) the cfg file generated by the ide can contain invalid settings (for
example imagebase, I believe this was fixed in D6 or D7).

Nick Hodges [TeamB]

unread,
Sep 7, 2004, 10:10:02 AM9/7/04
to
Vincent Parrett (Atozed Software) wrote:

> You cannot override most settings in the dpk from the command line or
> cfg file.

Hmm. I stand corrected.

Ottar Smidesang Holstad

unread,
Sep 7, 2004, 10:27:27 AM9/7/04
to
> BTW, the way finalbuilder deals with the compiler settings is to generate
a
> projectname.cfg file for use by the command line compiler.....

Doe! (see my other post...)


Reply all
Reply to author
Forward
0 new messages