Which branch for most recent lcidlc?

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

Locked
monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Which branch for most recent lcidlc?

Post by monte » Tue Jan 13, 2015 6:07 am

Hi @runrevmark

I need to rebuild all my externals fairly quickly for 64 bit support. It looks like the develop-6.7 doesn't have the latest lcidlc stuff but develop-7.0 does. Anyway, I'm hoping that the generated code from that will work for 64 bit build but before I can work out that I need to compile the thing... it's choking on unicode/uloc.h in lib foundation... can't find it. I made sure third party is updated. Any clues would be appreciated.

Cheers

Monte
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Which branch for most recent lcidlc?

Post by monte » Wed Jan 14, 2015 12:35 am

So I'm a little bit confused. I think I've chased down that all the unicode stuff is meant to be in prebuilt which is apparently no longer a submodule on this branch however this now makes even less sense that I don't have files I'm meant to have. If my prebuilt wasn't on the right commit then that would have been the logical culprit.... what am I missing? Anyone?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: Which branch for most recent lcidlc?

Post by LCMark » Wed Jan 14, 2015 2:20 pm

@monte: The 6.7 externals interface and lcidlc has not changed... All the changes are in 7.0 and thus on the develop-7.0 branch. With 7.0 we eliminated the prebuilt submodule, it is now just a folder. To get this setup with what you need to build lcidlc you just need to:
  • Switch to develop-7.0 (and make sure it is up to date)
  • cd prebuilt
  • ./fetch-libraries.sh
The final step downloads all the prebuilt binaries that would be a pain to compile a-fresh each time (there are also scripts in there for building them from source also) - the libraries fetched like this include ICU and OpenSSL.

In terms of externals themselves, 7.0 has a few changes (internally) to the externals API but this should be all entirely backwards-compatible when used in combination with lcidlc (and the glue code in support.mm) - so, modulo things we've missed, if you rebuild your externals with 7.0 branch lcidlc they should work with both 6.7 and 7.0 (unless you use 7.0-specific - unicode related - features).

I know there is an issue at present with the NS/CF bridge in Support.mm - this is because the array API in pre-7.0 is incompatible with the way 7.0 does arrays. This is being solved by moving the NS/CF bridge code into the engine (so the engine knows how to give you an array as an NSArray, for example).

@runrevsebastien has been the principal person who worked on updating both the old and new externals interfaces with unicode support, and ensuring things work with both 6.7 and 7.0 - if you get any issues either post a bug-report, or start a thread here and I'll make sure he keeps an eye out to lend a hand.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Which branch for most recent lcidlc?

Post by monte » Wed Jan 14, 2015 11:55 pm

Thanks @runrevmark. Fetching libraries right now.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Which branch for most recent lcidlc?

Post by monte » Thu Jan 15, 2015 1:19 am

That worked nicely... so with the latest lcidlc it's still throwing errors on the bitmap handle stuff which is cast as int so as I don't use that I just commented out in support.mm and recompiled lcidlc. It compiles now but for some reason when I specify both armv7 and arm64 as architectures it's not making a fat binary... will try and debug that today.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Which branch for most recent lcidlc?

Post by monte » Thu Jan 15, 2015 2:45 am

It's very odd... calling xcodebuild on the command line with armv7 and arm64 seems to build a fat binary fine but having both architectures in the project settings and building in Xcode doesn't... it sorts me out but I don't know if that will cause problems for when you update the externals sdk.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: Which branch for most recent lcidlc?

Post by LCMark » Thu Jan 15, 2015 12:01 pm

@monte: It seems that 'revtestexternal' uses global config files ('Global Mobile') which set ARCHS_STANDARD to armv7 - removing this line means the Xcode default kicks in. Check the build settings for your external target and see what is coming up in the ARCHS list in build settings.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Which branch for most recent lcidlc?

Post by monte » Thu Jan 15, 2015 11:40 pm

Hmm... It was the ARCHS list in the build settings for the target that I was changing to "armv7 arm64". If I remove the armv7 it build arm64 and if I remove arm64 it builds armv7 but it doesn't build both together... When both are there if I look at the build output it only shows armv7... wonder if it's an Xcode bug? anyway at least it works with xcodebuild.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Which branch for most recent lcidlc?

Post by monte » Fri Jan 16, 2015 4:04 am

OK so big problem with this now. The data type enum in support.mm isn't backwards compatible. It looks like unicode types were inserted between the basic c data types and the objective c ones. There's a note:

Code: Select all

// SN-2014-07-16: [[ ExternalsApiV6 ]] Enum updated to match
    //  the enum declared in externalsv1.cpp in the Engine
So I assume someone also changed the values in engine which of course means existing externals also aren't forwards compatible... Is this something you guys will fix?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Which branch for most recent lcidlc?

Post by monte » Fri Jan 16, 2015 4:23 am

Ah, further investigation reveals Core Foundation types were inserted after each corresponding Foundation type so I'd suggest either:

change

Code: Select all

#ifdef __HAS_CORE_FOUNDATION__
    kMCExternalValueOptionAsNSNumber = 17,
    kMCExternalValueOptionAsCFNumber = 18,
    kMCExternalValueOptionAsNSString = 19,
    kMCExternalValueOptionAsCFString = 20,
    kMCExternalValueOptionAsNSData = 21,
    kMCExternalValueOptionAsCFData = 22,
    kMCExternalValueOptionAsNSArray = 23,
    kMCExternalValueOptionAsCFArray = 24,
    kMCExternalValueOptionAsNSDictionary = 25,
    kMCExternalValueOptionAsCFDictionary = 26,
#endif
to

Code: Select all

#ifdef __HAS_CORE_FOUNDATION__
    kMCExternalValueOptionAsNSNumber = 17,
    kMCExternalValueOptionAsNSString = 18,
    kMCExternalValueOptionAsNSData = 19,
    kMCExternalValueOptionAsNSArray = 20,
    kMCExternalValueOptionAsNSDictionary = 21,
    kMCExternalValueOptionAsCFNumber = 22
    kMCExternalValueOptionAsCFString = 23,
    kMCExternalValueOptionAsCFData = 24,
    kMCExternalValueOptionAsCFArray = 25,
    kMCExternalValueOptionAsCFDictionary = 26,
#endif
Then revert the changed values in LiveCode.h

or only implement the Foundation types and folks can toll-free `__bridge` themselves or add simple variants in support.mm to return the bridged variants. I'd vote for just letting folks bridge themselves if they need to for simplicity.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: Which branch for most recent lcidlc?

Post by LCMark » Tue Jan 20, 2015 10:42 am

@monte: Thanks for the heads-up, I'll get @runrevsebastien to take a look. In regards to NS vs CF, the difference is in the memory management policy - the NS types are autoreleased, the CF ones are not. This just comes about from how one might expect to use return values - in obj-c you tend to expect APIs to autorelease values of the 'basic' types; whereas in CF it tends to be caller-release.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Which branch for most recent lcidlc?

Post by monte » Tue Jan 20, 2015 10:33 pm

Thanks @runrevmark
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Locked

Return to “Engine Contributors”