After encountering this problem I made the following change to the build system to sync the tinycbor repo to a particular tag, rather than whatever the state of the local repo happens to be: https://gerrit.iotivity.org/gerrit/#/c/14165/
The mbedTLS dependency is already synced in a similar manner. This change went in after 1.2.0 was shipped, of course. But from 1.2.1 this should be handled for tinycbor. I haven?t examined any of the other upstream dependencies for similar nondeterminism in the build process. Since the dependencies are each assigned to a particular project and its maintainers, perhaps they should have an action item to make sure the build system syncs their owned dependencies to a particular version. As for archiving the state of upstream dependencies each time a release is made, if there?s a concern about tags moving or repos/tarballs disappearing, this sounds like a task for the Release Management function to address as part of the release process. From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Heldt-Sheller, Nathan Sent: Sunday, November 20, 2016 11:52 AM To: 'Gregg Reynolds' <dev at mobileink.com>; Nivedita Singhvi <niveditasinghvi at gmail.com> Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] 1.2.0 build failure Hi Gregg, Nivedita, 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 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. 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?) Thoughts? Thanks, Nathan From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Gregg Reynolds Sent: Saturday, November 19, 2016 2:34 PM To: Nivedita Singhvi <niveditasinghvi at gmail.com<mailto:niveditasinghvi at gmail.com>> Cc: iotivity-dev at lists.iotivity.org<mailto: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/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.iotivity.org%2Fgerrit%2F%23%2Fc%2F14179%2F&data=02%7C01%7Ckkane%40microsoft.com%7C06ca1d85f340410900cf08d4117eb105%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636152683213205591&sdata=fOiDapu%2B8Uwx%2BlX5hOoQ7LuZoUMcF81RUu0%2FZ70DzeA%3D&reserved=0> > > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161121/c7ff3e74/attachment.html>
