LiveCode Forums.

What's the advantage in TARGET_SUBPLATFORM_IPHONE and ANDROID ?

Why not use __ANDROID__ and TARGET_OS_IPHONE ?

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.

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...

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

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.

BTW what's the license on libexternal?

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.

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...

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.

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...

I guess we could have something like this at the top in this case?

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).

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...

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.

Let me ponder the libexternal thing - you've actually given me an idea which I need to sit on for a wee while.

Let me ponder the libexternal thing - you've actually given me an idea which I need to sit on for a wee while.

Sure, no problem