IoTivity sample apps would be built by including only header files from /out. That's becomes part of our sanity testing that the contents of /out make sense.
Apps that are not part of IoTivity should follow the same good practice above. So, in your example, the apps under resource/cloudfoo/examples should include just Public headers. Headers that are intended to be Public from resource/cloudfoo/include would get published under /out by env.UserInstallTargetHeader() in SCons. Dan -----Original Message----- From: Mats Wichmann [mailto:[email protected]] Sent: Thursday, April 6, 2017 1:46 PM To: Dave Thaler <dthaler at microsoft.com>; Gregg Reynolds <dev at mobileink.com>; Daniel Mihai <Daniel.Mihai at microsoft.com> Cc: uzchoi at samsung.com; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Public and Experimental Public C APIs On 04/06/2017 02:27 PM, Dave Thaler wrote: > Well not having experimental stuff in the main branch would be a change to > current practice as there?s lots of stuff today that I would claim is > experimental. > I would have no objection to such a change, but it might be hard to get > others to agree with it. > > From: Gregg Reynolds [mailto:dev at mobileink.com] > Sent: Thursday, April 6, 2017 12:47 PM > To: Daniel Mihai <Daniel.Mihai at microsoft.com> > Cc: uzchoi at samsung.com; Dave Thaler <dthaler at microsoft.com>; > iotivity-dev at lists.iotivity.org; Mats Wichmann <mats at wichmann.us> > Subject: Re: [dev] Public and Experimental Public C APIs > > > > On Apr 6, 2017 2:09 PM, "Daniel Mihai via iotivity-dev" <iotivity-dev at > lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>> wrote: > Should we start with the following definitions? > > 1. All C functions included under out/<path_to_IoTivity_SDK>/ are Public APIs > 2. All C functions included under out/<path_to_IoTivity_SDK>/experimental/ > are Experimental Public APIs > > wait. the reason we have things like git is because it allows to avoid this > sort of thing (among other things). the main branch should _never_ include > experimental stuff, IMHO. that's what branches are for. I seem to be missing some of this thread, but... I don't mind a structure that makes it clear what's a "stable" API and what's not, that's great, assuming we're ready to declare anything "stable" at this moment. It's just it all continues to be confusing to me. It you put some code into a new area, let's say I've decided to propose a new directory resource/cloudfoo, and underneath that I've made directories include, examples, src and unittests. That's moderately consistent with what we have elsewhere (except the new IPCA tree has decided to use different names for a couple of those, hint hint... do we actually want a consistent tree structure? or is that just being too pedantic?) Now... when I set up the code in examples/, do I expect those examples to be copied to out/ and built there? Or do I expect to build them in place? If I'm building in place, I'm going to use -I./includes and put /#include "newheader.h"/ in my source files. But if I'm copying to out/ and building there, I have to place my new headers into an experimental subdirectory and put /#include "experimental/newheader.h"/ into the source files?
