You are not logged in.
I recently discovered that Synopse.inc has this code:
{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
I don't understand why, but for 64 bit targets only, this means that any DUnit projects that include a unit that includes Synopse.inc, fail to enumerate test methods. I'm building with XE3.
It seems to me that these options should not be specified in the Synopse.inc file. The appropriate place for them is in the .dpr file. Since they have an impact on the entire project, it feels wrong that they appear in Synopse.inc.
Offline
The 64 bit issue did not appear by us.
But we do not use DUnit, but the test classes included within SynCommons, which relies on "old RTTI".
I do not understand why it impact the entire project, whereas they are meant to be local.
http://docwiki.embarcadero.com/RADStudi … e_(Delphi)
http://docwiki.embarcadero.com/RADStudi … e_(Delphi)
Sounds like a XE3 bug.
You can just comment this part of the Synopse.inc content to circumvent this bug.
Offline
Yes, I know I can comment this out. But if Synopse.inc breaks RTTI in my project, for sure it will affect others. Anyway, I can work around it, but you may wish to dig a bit deeper for the benefit of your other users.
Offline
I confirm it brokes my RTTI also. XE2-XE4 as far as I tried, maybe other versions too.
It has been commented here.
Every time after full BUILD the problem occurs. Then if I modify only one unit and COMPILE, everything runs ok then.
Offline
Pretty weird.
Half-backed implementation?
If we put a conditional which will remove the new RTTI if defined, does it make sense to you?
What is your proposal for a name?
These settings were just in Synopse.inc to reduce the exe size for our internal projects.
It will definitively be less confusing if the default is to generate the new RTTI -even if it creates monstruous content!
Offline
Yes, it is very weird. I've not yet isolated the fault into an SSCCE so that a QC report can be logged. Or perhaps there already is one.
Anyway, thanks for listening and understanding. As for the naming of a conditional, I won't make a suggestion. You know your users better than anyone and I'm sure you'll come up with a sensible name that follows your existing conventions and naming patterns.
Offline
We have added a NEWRTTINOTUSED conditional.
It is unset by default, for compatibility.
See http://synopse.info/fossil/info/9394e4600b
It should circumvent the compiler problem, and not change the default behavior.
Thanks for the feedback
Offline
FWIW it was this bug that caused this: http://qc.embarcadero.com/wc/qcmain.aspx?d=79943
Offline