On Wed, Jun 15, 2016 at 5:33 PM, Trevor Bramwell < tbramwell at linuxfoundation.org> wrote:
> Dear Developers, > > I'd like to make a suggestion for the addition of a OFFLINE_BUILD flag > to Scons. By default this flag would be false, and allow anyone running > scons to have dependencies downloaded as they are needed. Setting > OFFLINE_BUILD to true would cause any attempt to download dependencies > to raise an error and produce the usual 'This dependency can't be > found. Please download it here:' message. > > This would be very helpful in alleviating the concerns some have raised > over having to do the 'busy work' of downloading dependencies in order > to build IoTivity. It would also allow the build servers to hopefully > run without talking to the network: producing faster and more consistent > builds. > Hi Trevor! 100% agreed with the idea, but let's think a little more about the best way to do it. I'm afraid I find the idea of an OFFLINE_BUILD flag a little clunky; I think we can do better. There's nothing wrong in principle with downloading dependencies; it all depends on how seamlessly you do it. I'm a Clojure guy myself, and in that ecosystem downloading deps is totally normal but also mostly invisible. The critical point of difference is that whereas the Iotivity build downloads stuff to project-local directories (e.g. extlibs/gtest), with Clojure build tools (which are unapologetically parasitic on maven), downloads get stored in a user-global directory, specifically ~/.m2/repository. So components only get downloaded once, even if they are used in many different projects. If you want a hands-on experience of this, hie thee to http://boot-clj.com/, install boot, then run "$ boot repl`. Boot will download a boatload of jars to ~/.m2/repository, then start up a Clojure repl. Then next time you do this, it will check ~/.m2/repository and see that it doesn't need to download anything else - no matter which project you're using. The problem with the Iotivity build system is not so much that it downloads stuff, but that it downloads it to extlibs/. So every time you scons a pristine version you download all over again. So one possible resolution of this might be to download to e.g. ~/.iotivity.d/ and then always check there before downloading again. A problem is versioning. The system Clojure tools uses involves maven IDs, which include both the component name and its version. Plus it's Java, which means it's semi-independent of the OS filesystem. Iotivity currently just says in so many words "lets download this file/repo" as opposed to "this widget, with this version". I'm not sure how to address that; suppose Iotivity wants version X of (say) libssl, and the user has installed version Y. The feature test might detect libssl, but as as far as I know feature testing cannot deal with versions, so things might break at runtime due to versioning stuff. Talkin' out my hat here, just sayin'. A related issue: what belongs in extlibs and what in resource/csdk? For example, I cannot see why cJSON is treated as an external lib. Ditto for tinycbor, and probably tinydtls. There is no reason to download these, and in fact except for tinycbor their code is already embedded in code base; why is it not in resource/csdk? If tinydtls is embedded in the codebase, why not tinycbor? One more thing: downloading the Android SDK is just a really bad idea, IMO. I already have an Android SDK; the default should be to use that. DItto for gradle. Ditto for NDK. HTH, -g -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160615/d4d1fa07/attachment.html>
