Question to component developers: Is there any global variable or define to recognize Studio "Starter" edition at compile-time ?
Question to component developers: Is there any global variable or define to recognize Studio "Starter" edition at compile-time ?
{$IF IsStarter}
...
{$ENDIF}
{$IF IsStarter}
...
{$ENDIF}
would be interesting for Professional an Enterprise, too.
ReplyDeleteNo, what exactly do you want to check for?
ReplyDeleteI have units and runtime packages that depend on FireDac, RestComponents, etc, and I want to exclude them when our automatic recompile tool compiles them. That tool comments out the non existing packages from the requires section (no ifdef needed here), but the units have "uses" that depend on conditional ifdefs (these are the ones I'd like to be changed to something)
ReplyDeleteThen you need to provide a "COMPILE_FOR_STARTER" define to the projects via your automatic recompile tool.
ReplyDeleteFWIW I would rather have ifdefs for specific features though rather than checking a specific SKU.
If you are checking these things in too many places I would review the package architecture because it might be wrong. This is btw one of the reasons why vendors that do DB aware things often have a huge amounts of packages because they have them for every supported third party component. I would consider doing the same here. Make a core package and then some for FireDAC, Rest, and so on.
Stefan Glienke yes thats the part I want to avoid, because when people compile projects using that unit, that define should also be there, instead of telling people to "add this define to project or env options", the automatic tool modifies the affected units and the typical mydefs.inc include, adding forced that define. The problem is (not for everybody), if you have both Starter and other Studio versions that are not Starter, then that forced defines are not valid for all ides
ReplyDeleteMy opinion is that third party packages should not differ based on the SKU or the features you purchased but be the same for everyone. If you support any "optional" things then put them into another package. Everything else creates a huge pain when using these packages by other packages.
ReplyDelete