On 11/20/2016 11:51 AM, Heldt-Sheller, Nathan wrote: > Hi Gregg, Nivedita, >
Thanks for the response, Nathan. > I ran into the same build issue yesterday. IoTivity 1.2.0 worked > without issues when it was released. But it looks like the update to > TinyCBOR since then has broken the 1.2.0 release. As Kevin pointed out, > 1.2.0 release requires v0.3.2 of TinyCBOR. > > > > This seems to be a problem with our build script and/or release process > resolving dependencies on external repos (rather than an issue of > low-quality or untested releases!). Hopefully someone with better Agreed, and as I commented earlier, there are steps one can take if a code release breaks after it has been released. This would ordinarily be a non-issue, just one of many trivial bugs in the development of a sw project, if it were addressed so that it would not continue to trip up people. What baffles me is why the failure to do even trivial things so that it doesn't continue to bite others, and the assumptions that users can just move on to current git and manually download whatever's needed. Some of us are automating the pull and build process at our end, so scripts which see some msg like that are going to fail. The 1.1.1 release has broken for 3 months. Nothing on the download page nor the Release Notes page indicates that it will not build (hence the flow of user questions on -dev list): https://www.iotivity.org/downloads/iotivity-1.1.1 https://wiki.iotivity.org/release_note_1.1.1 Same with 1.2.0 (except the release notes wiki page for 1.2.0 now has a note I added at the top which indicates the problem) https://www.iotivity.org/downloads/iotivity-1.2.0 https://wiki.iotivity.org/release_note_1.2.0 (I am very willing to edit the wiki pages with the right information if I have it, and intend doing so for all of the above, if it helps, but I can't do anything about the downloads pages). > familiarity with scons will have a way to address this library version > dependency issue, because clearly we can?t expect developers to ?just > know? which version of TinyCBOR to pull in order to build a particular > version of IoTivity. While we can't avoid breakages like this, I think we can certainly fix them so that they don't remain issues. - Edit the downloads page - Edit the Release Notes page Even just giving users a heads up that this is an issue will go most of the way to resolving the current difficulties users have. Can push an updated point release out (1.1.2 with the build fix only, for example, a suggestion which got no traction) > I think for the time being, the right thing to do is update the IoTivity > 1.2.0 wiki pages to specify the exact versions of the external libs to > pull. Going forward, hopefully this dependency can be automated (or > perhaps just bundled with the release tarball?) For 1.2.1, I would like to see it automated, and have the build system download the right versions automatically, rather than have the user be told to manually d/l something (to avoid breaking automated scripts). Bundling all of the dependencies together with iotivity might be inefficient, especially if the right version is already present on the system. > Thoughts? > > Thanks, > Nathan > > > > > > > > *From:*iotivity-dev-bounces at lists.iotivity.org > [mailto:iotivity-dev-bounces at lists.iotivity.org] *On Behalf Of *Gregg > Reynolds > *Sent:* Saturday, November 19, 2016 2:34 PM > *To:* Nivedita Singhvi <niveditasinghvi at gmail.com> > *Cc:* iotivity-dev at lists.iotivity.org > *Subject:* Re: [dev] 1.2.0 build failure > > > > On Nov 19, 2016 4:29 PM, "Nivedita Singhvi" <niveditasinghvi at gmail.com > <mailto:niveditasinghvi at gmail.com>> wrote: >> >> On 11/19/2016 12:56 PM, Kevin Kane via iotivity-dev wrote: >>> >>> This should have been fixed on 1.2-rel with the following change, to >>> work with TinyCBOR v0.4: https://gerrit.iotivity.org/gerrit/#/c/14179/ >> >> >> >> How will they know? >> >> For anyone doing anything on top of iotivity, and who is not >> simply a developer contributing _to_ iotivity, they will want to >> pick up a known, stable release to base on. They will expect that >> to build. They will not want to base on a random dev tree snapshot. >> >> In addition, most developers will not hunt through the bug lists >> to see known bugs in a release before downloading and testing. At >> best, they will read the release notes. >> >> Most of the individual developers and maintainers are very good >> about helping to address issues when users run into them. But that's >> not a very scalable process, especially not as the iotivity user >> base grows, and pointing to fixes and workarounds in the dev trains >> is only helpful up to a point. >> >> >> I am imploring the iotivity community, please: >> >> * Keep in mind the user base (respect their time and effort) >> >> * Don't release with build failures >> >> * If for some reason after the fact a release tarball fails to build >> (as happened with 1.1.1), pull the build or mitigate in some way: >> >> - document issues clearly on release notes page >> - pull the broken build >> - push out an updated point maintenance release with build fix >> >> >> At this point, none of the existing releases of iotivity are usable >> as-is, without (undocumented) workarounds and patches. I would hope >> this is not the case going forward from 1.2.1 onwards. I am very >> appreciative of the fact that the team is releasing 1.2.1 asap, but am >> not sure they would have if std compliance wasn't broken as well. >> > > THANK YOU! at least I know I'm not alone. >> >> >>> >>> Are you up to date? >>> >>> >>> >>> If you?re working from an older point of the branch, you can get around >>> this by going into extlibs\tinycbor\tinycbor and doing a ?git fetch && >>> git checkout v0.3.2? to use the previous version of TinyCBOR. >>> >>> >>> >>> *From:*iotivity-dev-bounces at lists.iotivity.org > <mailto:iotivity-dev-bounces at lists.iotivity.org> >>> [mailto:iotivity-dev-bounces at lists.iotivity.org > <mailto:iotivity-dev-bounces at lists.iotivity.org>] *On Behalf Of *Gregg >>> Reynolds >>> *Sent:* Saturday, November 19, 2016 11:52 AM >>> *To:* iotivity-dev <iotivity-dev at lists.iotivity.org > <mailto:iotivity-dev at lists.iotivity.org>> >>> *Subject:* [dev] 1.2.0 build failure >>> >>> >>> >>> >>> $ scons >>> >>> >>> >>> ... >>> >>> >>> >>> resource/csdk/security/src/aclresource.c: In function 'AclToCBORPayload': >>> >>> resource/csdk/security/src/aclresource.c:628:24: error: 'CborEncoder' >>> has no member named 'ptr' >>> >>> *size = encoder.ptr - outPayload; >>> >>> ^ >>> >>> resource/csdk/security/src/aclresource.c:640:27: error: 'CborEncoder' >>> has no member named 'ptr' >>> >>> cborLen += encoder.ptr - encoder.end; >>> >>> ^ >>> >>> scons: *** >>> [out/linux/x86_64/release/resource/csdk/security/src/aclresource.o] > Error 1 >>> >>> scons: building terminated because of errors. >>> >>> >> >> >> thanks, >> Nivedita >> >> >
