<p dir="auto">I'm building a fairly large library for ios which is working great. Its about 20MB for each architecture.</p>
<p dir="auto">However, the build times are really starting to take their toll. They are now taking around 5 minutes to build which is tough for productivity. It would be great to be able to speed up these time by perhaps caching some of the build data.</p>
<p dir="auto">I'm not sure of the process but it seems for every build, bind generates a new random temporary folder for all the files, where perhaps, it could use a cached folder and reuse previously built object files?</p>
<p dir="auto">This can't really be called a bug, but it is potentially sub-par behaviour. It is a follow on from a suggestion I made in <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="102271048" data-permission-text="Title is private" data-url="https://github.com/golang/go/issues/12245" data-hovercard-type="issue" data-hovercard-url="/golang/go/issues/12245/hovercard" href="https://github.com/golang/go/issues/12245">#12245</a>.</p>
<p dir="auto"><code class="notranslate">gomobile bind</code> currently generates binding code every time it is run. This has the following side effects:</p>
<ul dir="auto">
<li><strong>Access to source for debugging:</strong> When debugging application errors in the wild, it is useful to have the source available. In the case of native libraries, we can use vendoring or the native package manager for versioning. With <code class="notranslate">gobind</code> however, the source is not easily available. It can be generated by manually running <code class="notranslate">gobind</code>, but there are a few concerns with this approach.
<ul dir="auto">
<li><em>The options passed to <code class="notranslate">gobind</code> are opaque to the user:</em> Currently there are no options, but if this changes in the future it becomes a guessing game.</li>
<li><em>Upgrades of the <code class="notranslate">gobind</code> tool can result in source changes:</em> For production releases we will need to track the exact version of <code class="notranslate">gomobile</code> used to generate the library. This is fine once <code class="notranslate">gobind</code> is stable (for example with cgo now). However, it is problematic for early adopters since changes are being made to <code class="notranslate">gobind</code> on a regular basis.</li>
</ul>
</li>
<li><strong>Incremental builds:</strong> In an SDK app, <code class="notranslate">gomobile bind</code> must be run on source changes to regenerate the new framework/aar. There are two ways of approaching this. Manually run <code class="notranslate">gomobile bind</code> or have the IDE (XCode/Android Studio) invoke it before compiling the ObjC/Java source. The former, while not a chore, can be error prone. The latter is more robust, but results in the framework/aar being rebuilt even if no go source is changed. This adds delays to the code -&gt; compile -&gt; test cycle and negatively impacts our workflow. It also takes away one of the advantages of go which are its near instantaneous build times.</li>
</ul>
<p dir="auto">One solution would be for <code class="notranslate">gomobile bind</code> to accept a command line flag which specifies the directory in which to generate code and then skip regenerating code on every run.</p>
<p dir="auto">This is more a nice to have rather than a need to have since there are workarounds present.</p>