These kinds of errors drive me nuts! I know this error is in the project file somewhere (compiler or linker setting), but can I get a clue as to what setting? I'm trying to enable the EurekaLog on a project. It won't work until I find where this is. When writing code I go out of my way to avoid generic errors like this. This is almost like a customer calling and stating your software doesn't work, what's wrong with it?
These kinds of errors drive me nuts! I know this error is in the project file somewhere (compiler or linker setting), but can I get a clue as to what setting? I'm trying to enable the EurekaLog on a project. It won't work until I find where this is. When writing code I go out of my way to avoid generic errors like this. This is almost like a customer calling and stating your software doesn't work, what's wrong with it?
This is error in dproj file connected to debug settings. Older projects had true/false for debug info, and newer (XE4/XE5) replaced that with integer to have multiple levels of debug info on mobile. I cannot remember more details on that issue, though.
ReplyDeleteDeleting dproj and recreating it should fix the error.
Go to Project Options -> Delphi Compiler -> Compiling.
ReplyDeleteIn the "Debugging" group locate the "Debug information" setting. In former Delphi versions, this was an True/False switch; starting with XE7 it is now a three-state value: "No Debug information", "Limited Debug information" and "Debug information".
Just change the setting to "Debug information" and this error should be gone.
HTH
Achim
For me this manifested itself in a different way: "error F1026: File not found: 'False.dpr" when building with msbuild. Likely the same cause. See http://wiert.me/2013/11/20/when-the-delphi-xe5-commandline-compiler-fails-with/
ReplyDeleteIf you can open the project go to Project options - Delphi-Compiler - Compile - Debug-Information and set the true value in one of the build configurations to a decent value from the drop down list.
ReplyDeleteThanks Dalija Prasnikar . I did find it, this has been just one of about 200 weird items that have popped up on my long path to get a D7 app up to XE7. Most were 3rd party components that had issues. For a while there I was about ready to give up. It seemed like too much was broken overall to continue. My D7 app was <20Megs. With Debug info on (Eureka Log requirement) compiled with XE7, it's 96Megs! WTF? I thought I had the RTL stuff turned off, looks like it's not. Time to hunt item 201 down.
ReplyDeleteAnd I agree that the error message should be more verbose, so that we don't have to hunt down the reason for this error.
ReplyDelete96MB is gigantic! But what size is the release version? That's the important one.
ReplyDeleteDavid Millington 76Megs! Ouch.. What's the proper way to turn of RTTI stuff now? I'm to the point where I'm testing and polishing. I had some code in the project file when I was working with XE4, but removed it at one point to eliminate it as potentially introducing an issue.
ReplyDeleteCurt Krueger Add this to the DPR file to disable new RTTI (note you will probably still want to disable old RTTI too):
ReplyDelete{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
Above the uses clause in the DPR, that is, not just "in" the DPR file.
ReplyDeleteBtw code in the DPR file should be fine - it's the .dproj file you need to fix or recreate.
FWIW XE7 is a great release and IMO well worth the time spent upgrading from D7. I hope you'll agree once everything's working. Welcome to the modern Delphi users group :)
RTTI is not what makes an application that fat. Cause number one is debug information in the exe (first option on the linker page). And before someone says: "that option is off in release config!" yes, it might be for a new project but it might not be on for a migrated one. And if eureka log required debug information (which I doubt) I would throw that into the bin and use madExcept which does not require that - though you might keep the map files around from a release build once you ship it so you can decipher a bug report a customer might send you (which does not contain the full method names but just addresses without debug info)
ReplyDeleteDavid Millington Thanks! Ok, that's more like it. 32.6Megs. Still a lot larger than D7, but a lot more acceptable than 96Megs!
ReplyDeleteDavid Millington That will not have any effect anymore since like XE5 or so XE6 when they fixed that directive. So everyone please stop giving out that advice - it just does not work anymore
ReplyDeleteStefan Glienke The {$RTTI...} directive (?) won't have any effect? What changed in XE5?
ReplyDeleteIt got fixed to only have unit scope as documented and intented. Working across unit boundaries was a bug (even if its effect was beneficial at times) http://qc.embarcadero.com/wc/qcmain.aspx?d=79943
ReplyDeleteStefan Glienke I didn't know that. I'll edit the relevant SO questions.
ReplyDeleteYou can use the "refind" utility included with Delphi to mass convert all your .dproj files if you like. Put the following in a text file, say "upgrade.refind":
ReplyDeletefalse -> 0
true -> 2
Then run the following command in your source folder where all your projects are located:
refind *.dproj *.dpr *.cfg /S /B:2 /I /X:upgrade.refind
You can set up the reverse mappings to allow you to downgrade/make the dproj files compatible with an older version again if you want. The above is copied from a batch file I wrote -- I don't remember exactly why I added in the *.dpr and *.cfg -- I think that's just defensive and the .dpr and .cfg should/can probably be removed. Also note /B:2 means no backup is created, and /I means changes are case insensitive.
In addition to adding what David Millington suggested, I found "Debug Information" under linking and set that to false as well (compared to the "Compiling" setting). So that is where I got the big decrease apparently. Thanks all for the info!
ReplyDelete