Jump to content
PeterPanettone

Release or Debug?

Recommended Posts

I have built GExperts [r4257] in Delphi 12.1 with the RELEASE build configuration (the default preset is the Debug build configuration).

 

Is there a performance advantage of the release configuration over the debug configuration?

Share this post


Link to post
Posted (edited)

The release config does not write to the debug window. There might be some other debug functionality too that's turned off. Of course the main difference is that it does not include debug info for the debugger. 

I don't think that there is a big impact on performance.

 

The default when building in the IDE is debug, when building with the build scripts it is release.

Edited by dummzeuch
  • Haha 1

Share this post


Link to post
Posted (edited)
50 minutes ago, dummzeuch said:

when building with the build scripts

The build scripts don't work - they showed an error. That's why I'm building in the IDE.

 

Strangely, AFTER having built the project in the IDE, the build script succeeded:

 

\gexperts-code-r4257-trunk\Projects\DelphiXx120\__Build_Project.cmd

Edited by PeterPanettone

Share this post


Link to post

"showed an error" is not really a good description... I guess some file was missing the automatically gets created by the IDE but not by the script.

  • Haha 1

Share this post


Link to post
9 minutes ago, dummzeuch said:

"showed an error" is not really a good description... I guess some file was missing the automatically gets created by the IDE but not by the script.

No, it's not that. I just checked out the sources to a new folder and i compiled fine for Delphi 12. No error message, no file(s) missing.

  • Haha 1

Share this post


Link to post

So maybe it's also related to the SVN issue. Making the behavior of a compiled executable dependent on something that is not in the source is simply IRRATIONAL. That would be the same as making the behavior of the executable dependent on the weather at the compile time.

Share this post


Link to post

Making the behavior of a compiled executable dependent on something that is not in the source is simply IRRATIONAL.

No, that is way to over-simplified.

If there is something that the build-script generate every time you run a build (pre- and post-build scripts) then the intermediate files should *not* be part of the version control, because they get regenerated each and every time you start a new build.

However it should build using the scripts.

Share this post


Link to post
17 hours ago, PeterPanettone said:

So maybe it's also related to the SVN issue. Making the behavior of a compiled executable dependent on something that is not in the source is simply IRRATIONAL. That would be the same as making the behavior of the executable dependent on the weather at the compile time.

Maybe I should simply turn off source code downloads from SourceForge ...

  • Haha 4

Share this post


Link to post

How about creating a "release" Script?

 

That would compile the files and write the build-version to an include file. Then it would bundle that include file with the source and the pre-built bpl file as a release file?

Share this post


Link to post
30 minutes ago, baka0815 said:

How about creating a "release" Script?

 

That would compile the files and write the build-version to an include file. Then it would bundle that include file with the source and the pre-built bpl file as a release file?

This is not about how to add the build number to the executable, but that the existing build script uses the svn revision as the build number, which is 0 if the sources are not checked out but downloaded as zip file from sourceforge. So there is already an automatic way to add the version number to the dll. There is also a script for generating the installer(s).

Share this post


Link to post
On 5/26/2024 at 8:14 PM, PeterPanettone said:

Making the behavior of a compiled executable dependent on something that is not in the source is simply IRRATIONAL.

Of course it is possible to write the SVN revision number into the source, but when you commit that change to SVN it gets a new revision number. That's why SVN replaces a special keyword in the sources with the current revision number.

 

Letting alone that the concept of a revision number is some SVN thing and has no counterpart in most of the other version control systems for several reasons.

 

The more I think about it the more I like the no-downloads approach...

Share this post


Link to post
2 hours ago, Uwe Raabe said:

The more I think about it the more I like the no-downloads approach...

I am taking yet another different approach: The "If you download the sources, the buildnumber will 0. Live with it." approach.

  • Like 3

Share this post


Link to post
35 minutes ago, dummzeuch said:

I am taking yet another different approach: The "If you download the sources, the buildnumber will 0. Live with it." approach.

You missed attaching this image as explanatory material

image.thumb.png.60af5f17a2dfcc10763aa6839ec42a90.png 

 

Joking aside :

How to use a script to add datetime on checkin like leaving the rversion 0 or whatever to minimize breaking changes, but with an extra string like 202405281850 ?

Is that is easy/feasible with SVN ? 

Share this post


Link to post
Quote

The "If you download the sources, the buildnumber will 0. Live with it." approach.

Bravo!  And please do not abandon a simple source download, for people like me who dislike having to struggle to work around an unnecessary version-control system to get what I need.

  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×