[TIMOB-25642] Discussion: Allow native modules to be included without compiling them
| GitHub Issue | n/a |
|---|---|
| Type | Story |
| Priority | None |
| Status | Open |
| Resolution | Unresolved |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | Android, iOS, Windows |
| Labels | n/a |
| Reporter | Hans Knöchel |
| Assignee | Unknown |
| Created | 2018-01-03T15:09:06.000+0000 |
| Updated | 2018-08-09T07:47:44.000+0000 |
Description
This is open for discussion: Some other frameworks allow developers to use their native modules without compiling them before. While this decreases the speed of clean builds, it gives the huge advantage of not needing to recompile native modules if a new V8 version comes out, since it's tied to the V8 version of the SDK.
From a technical perspective, we would then compile native modules on the fly and store a reference of them for recurring builds. Even if we decide to not do this, it could be realized without too much effort by using a hook that scans the modules/ directory for uncompiled modules, builds them with the existing utility and links it to the app like before.
Thoughts welcome!
I'm all for this! My initial instinct is to treat modules like we do Watch apps and copy the targets from the module's Xcode project into the generated Titanium app's Xcode project, then set up the dependencies. This will allow us to continue to call
xcodebuilda single time and let Xcode manage the derived data. This will also allow us, in theory, to be able to open the generated Xcode project and interactively debug modules with ease. Implementing this in the current Titanium iOS build is possible, but tricky. The code that does the differential builds is delicate to say the least. I'm sure there's code in a few places that carefully handles iOS extension and Watch app projects. Since we need to a way to distinguish which modules in the<project-dir>/modules/iosshould use the pre-compiled version or merge into the generated Xcode project, we need to add a new attribute to the<module>tag in thetiapp.xml. Not sure the name, but maybecompile="true"orembed="true". FYI, extensions have their<extensions>tag. So, this isn't impossible, but it won't be easy to implement. We need to be very careful to not break the differential build code.Sorry for the late response [~cbarber], but appreciate your thoughts! I really think this a fundamental improvement we need to do moving forward, as our V8-updates will likely cause breaking changes for every version, making maintenance impossible at some point (speaking as a Titanium dev who's around for 7+ years). From an architectural standpoint, I wouldn't even add a
compile="true"and be smart enough to detect it automatically. For iOS, it could be the *.xcodeproj presence or non-presence of a *.a (static library, objc) or *.framework (dynamic framework, Swift). For Android, it could be the non-presence of the generated libs/ directory and it's *.so files. Or even simpler, by having manifest keycompile: trueto let the module dev decide whether or not to compile before packaging. The change for the build "pipeline" could then be relatively slim by checking the manifest (or the above indicators), linking the targets (on iOS as simple as calling [addTargetDependency](https://github.com/alunny/node-xcode/blob/master/lib/pbxProject.js#L771) fromnode-xcodewe use, together with some asset management and additional linking. But the work would be worth it. I am also very interested in the deep dive for Android, if [~jquick] has some thoughts :-). May be a SDK 9'ish thing.