TARGET_SUBPLATFORM macros
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
TARGET_SUBPLATFORM macros
What's the advantage in TARGET_SUBPLATFORM_IPHONE and ANDROID ?
Why not use __ANDROID__ and TARGET_OS_IPHONE ?
Why not use __ANDROID__ and TARGET_OS_IPHONE ?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: TARGET_SUBPLATFORM macros
Consistency... Clarity... The TARGET_SUBPLATFORM_* macros are the ones that are used to distinguish between code for those two platforms in the current engine branch in an attempt to make what are quite platform-specific things a little more uniform...
The macros various different platform/compiler combinations define to describe themselves tend to be a little inconsistent (e.g. __ANDROID__ and TARGET_OS_IPHONE) thus deriving more uniform ones seems to make sense in a cross-platform project.
This is clearer in the refactored branch (take a look at libfoundation/include/foundation.h) - here various compiler target options (expressed in a per-compiler way through defines) are massaged into uniform macros that can be used throughout. For example, in that branch if you want to check for 64-bit intel processor you use __X86_64__ - even though visual C declares this using _M_X64, and GCC as __x86_64__. We still need to go through the code in that branch and switch-over to using the new style everywhere, but that's part of a code cleanup step we'll do a bit further down the line.
The macros various different platform/compiler combinations define to describe themselves tend to be a little inconsistent (e.g. __ANDROID__ and TARGET_OS_IPHONE) thus deriving more uniform ones seems to make sense in a cross-platform project.
This is clearer in the refactored branch (take a look at libfoundation/include/foundation.h) - here various compiler target options (expressed in a per-compiler way through defines) are massaged into uniform macros that can be used throughout. For example, in that branch if you want to check for 64-bit intel processor you use __X86_64__ - even though visual C declares this using _M_X64, and GCC as __x86_64__. We still need to go through the code in that branch and switch-over to using the new style everywhere, but that's part of a code cleanup step we'll do a bit further down the line.
Re: TARGET_SUBPLATFORM macros
OK... I was integrating your libexternal tweaks to get it working on iOS into mergJSON and in that instance it was a bit annoying so in my copy I've replaced them with the usual macros
BTW what's the license on libexternal?
Ah... also, I hesitate to suggest it but libexternal would be a good candidate for a submodule so it can be incorporated into other projects more easily...
BTW what's the license on libexternal?
Ah... also, I hesitate to suggest it but libexternal would be a good candidate for a submodule so it can be incorporated into other projects more easily...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: TARGET_SUBPLATFORM macros
That's fair enough - especially since it gets integrated into other projects and thus requiring it to include the engine's sysdef-type headers would be a pain.OK... I was integrating your libexternal tweaks to get it working on iOS into mergJSON and in that instance it was a bit annoying so in my copy I've replaced them with the usual macros
Good question - I don't think that has ever been defined - it certainly needs to be something other than GPL... Similar story for lcidlc and the code it incorporates into the generated code. I shall ponder and get back to you.BTW what's the license on libexternal?
I'll ponder it - I guess libexternal is essentially frozen (the next change will be when it turns into a shim to talk to the new Extensions API, and that will be the last) so maybe it makes sense. My main resistance is the fact that submodules are a PITA, and I'm reticent to have any more linked to from within the livecode repository.Ah... also, I hesitate to suggest it but libexternal would be a good candidate for a submodule so it can be incorporated into other projects more easily...
Re: TARGET_SUBPLATFORM macros
I guess we could have something like this at the top in this case?
Regarding the submodules I understand... I actually think you could drop the other three submodules. The main reason for submodules I see is incorporating into multiple projects... libexternal is the only thing...
Code: Select all
#ifndef TARGET_SUBPLATFORM_IPHONE
#if TARGET_OS_IPHONE
#define TARGET_SUBPLATFORM_IPHONE
#endif
#endif
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: TARGET_SUBPLATFORM macros
I think in this instance just using the 'native' macro is fine - apart from anything else, it's only used once after all and that file isn't going to be changing for a while (and then only once more).I guess we could have something like this at the top in this case?
The reason for the three submodules that were there is to stop the main livecode git repository getting bloated with things that can be derived from elsewhere. It's on the list at some point to clean this up - but, on the whole things are working fine for now, the submodules aren't updated all that often and there are bigger fish to fry in the short term.Regarding the submodules I understand... I actually think you could drop the other three submodules. The main reason for submodules I see is incorporating into multiple projects... libexternal is the only thing...
Let me ponder the libexternal thing - you've actually given me an idea which I need to sit on for a wee while.
Re: TARGET_SUBPLATFORM macros
Sure, no problemLet me ponder the libexternal thing - you've actually given me an idea which I need to sit on for a wee while.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/