On 06/15/2016 06:55 PM, Gregg Reynolds wrote: > > > On Wed, Jun 15, 2016 at 5:33 PM, Trevor Bramwell <tbramwell at > linuxfoundation.org <mailto: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. >
There's never anything simple about these hybrid situations. Typically (auto)builders operate pretty differently from how a developer does. In most situations a developer is happy to maintain state from build to build, and only if something goes wrong do you want to clean out and start over to make sure you're not getting bitten by some artifact. As noted above, there's also the conflict of iotivity being known to work with a specific version of something, and it may or may not be safe to instead just use the version supplied by that "distro" (to use the Linux term generically) - boost, gradle, whatever. A builder, on the other hand, typically wants a completely clean state each time (although caching a tarball or some such is reasonable, similer to what's noted by Gregg above) - assume nothing and start clean, using exactly what's specified by the build process. Some of the recent discomfort seems to have been around cases where the one usage model isn't really in agreement with the other: "this patch fixes my problem" ... "hey, that broke the [XXX] builder". It's not like this is a brand new problem to IoTivity, it's been going on for ages in projects. Just so nobody forgets.... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160615/43b73c4c/attachment.html>
