PeterPanettone 158 Posted May 25 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
dummzeuch 1509 Posted May 26 (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 May 26 by dummzeuch 1 Share this post Link to post
PeterPanettone 158 Posted May 26 (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 May 26 by PeterPanettone Share this post Link to post
dummzeuch 1509 Posted May 26 "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. 1 Share this post Link to post
dummzeuch 1509 Posted May 26 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. 1 Share this post Link to post
PeterPanettone 158 Posted May 26 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
baka0815 12 Posted May 27 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
dummzeuch 1509 Posted May 27 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 ... 4 Share this post Link to post
baka0815 12 Posted May 28 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
dummzeuch 1509 Posted May 28 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
Uwe Raabe 2061 Posted May 28 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
dummzeuch 1509 Posted May 28 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. 3 Share this post Link to post
Kas Ob. 121 Posted May 28 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 ? Share this post Link to post
timfrost 78 Posted May 28 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. 1 Share this post Link to post