Release or Debug?

[PeterPanettone 158]

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?

[dummzeuch 1515]

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 May 26 by dummzeuch

[PeterPanettone 158]

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 May 26 by PeterPanettone

[dummzeuch 1515]

"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.

[dummzeuch 1515]

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.

[PeterPanettone 158]

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.

[baka0815 12]

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.

[dummzeuch 1515]

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 ...

[baka0815 12]

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?

[dummzeuch 1515]

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).

[Uwe Raabe 2063]

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...

[dummzeuch 1515]

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.

[Kas Ob. 121]

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

 

 

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 ? 

[timfrost 79]

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.