IOS builds broken

[Dave Dyer]

5 IOS builds in a row have failed with this error:

/Release-iphoneos/Develop.build/Objects-normal/armv7/com_codename1_ui_geom_GeneralPath.o
/var/folders/zh/kb_4hqhn4kg1h0r5dp_6htcm0000gn/T/build7366153678036003995xxx/dist/Develop-src/com_codename1_ui_geom_GeneralPath.m:1011:1: error: expected statement
}
^
1 error generated.

[Carlos Verdier]

I'm not having errors but builds are extremely slow right now for iOS. Over 30 minutes.

[Steve Hannah]

I can't seem to reproduce this.  And I'm building an app that has full coverage in GeneralPath.  Are you doing a versioned build?

Steve

[Steve Hannah]

I've run every demo I have at it and can't reproduce this problem.   I've checked that GeneralPath has full coverage, so I'm at a loss on this error.  You'll need to provide a test case.

Steve

--

Steve Hannah

Software Developer

Codename One

http://www.codenameone.com

[Dave Dyer]

Sixth attempt at the same build was successful.   I suspect that a particular
server had a problem, and it was the luck of the draw that determined how many attempts
are needed to succeed.  It would be useful if the error log included some kind of server id.

[Shai Almog]

I'm guessing slower builds are a result of some tests by Dave/us that flooded the iOS build queue.

@Dave Did you test your thesis by changing the generated code and rebuilding after the change or is it just a working theory?

[Dave Dyer]

I just kept trying the same build, with no changes, until one succeeded.

[Shai Almog]

I was talking about the multiple header include theory

[Dave Dyer]

yes.  i rearranged some dependencies that were fairly easy to change and got a 50% decrease
in build times.  to do this systematically i proposed to rewrite the header files to separate the
exported apis from all the internal declarations, so only the external headers need be included.

as it is now, if a class uses a crapload of other classes, but exports only a trivial interface,
every other class that imports it also imports all the irrelevant crap.  The effect in complex
hierarchies is every class ends up importing everything.

[Shai Almog]

Are they the headers included as part of the dependency block: https://github.com/codenameone/CodenameOne/blob/1ac7c6192cae151cb1665888d4a16175d56ef892/vm/ByteCodeTranslator/src/com/codename1/tools/translator/ByteCodeClass.java#L1011-L1019

If so do you have any concrete suggestions for optimizing that and detecting the cases where something isn't needed?

[Dave Dyer]

My understanding of the standard Java compilation process is that you (conceptually) parse the .class file, and that tells you everything you are allowed to know about the class. so if you built a header file that way, that would be all that is needed for any other file that uses the class.

The header file you are currently producing is a superset, sometimes a vastly larger superset, of
That minimal header. The header you're producing is needed to compile the class, but not to use it.

[Shai Almog]

The link I provided is literally to the translation code, notice it's just plain Java code that generates the C headers.

[Dave Dyer]

Suppose I have a class that includes everything imaginable, but provides only a single parameterless method called DoIt()
If some other class uses it, it needs only a header that includes DoIt(), not all the rest of the classes in the world. It is
Admittedly a little more complicated to provide correct headers for private and protected interfaces, but the fundamental
Distinction between the classes it uses and the interfaces it provides is well defined.

[Shai Almog]

I understood that premise before.
Notice that you probably built a debug version which is more lenient in terms of C syntax. Release versions are more strict and if a feature is used that hasn't been declared they will fail.

Also keep in mind that precompiled headers really impact build times so it might also impact things significantly.