Great to know I was not the only one who dislike scons. Never worked with Bazel. Still think that make/autoconf are the greatest tools in software :) I think that if a bold switch to make is done, it will be a great step forward at least to break the barrier for a learning curve for another build environment.
Also, the re-organization of source code was much needed. I think usage of makeheaders is quite nice. Never used it though. So, how does it resolve which auto-generated .h is used by a certain .c file. I mean if somefile.c originally uses both somefile.h and another_file.h, how does it make sure somefile.c dependencies are resolved? So, how do you plan to maintain updates with iotivity releases. Would this be a separate fork to evolve independently or when iotivity is updated, openOCF will be updated? Khaled On Fri, Dec 1, 2017 at 4:19 PM, Gregg Reynolds <[email protected]> wrote: > Hi list, > > OpenOCF <https://github.com/OpenOCF/iochibity> (formerly Iochibity) seems > to build and run on Ubuntu, macOS Sierra, and Windows 7, with support for > cross-compiling to the Raspberry Pi 3B. > > This is a fork of Iotivity. The original goal was modest: strip out all > the C++ stuff, leaving a minimal kernel - essentially csdk. But then one > thing led to another, and, well, if it's but a step from the sublime to the > ridiculous why be so timid? Why not leap about like a deranged billly goat > on a craggy mountainside? The result is that now OpenOCF looks very > different than Iotivity even though the code is almost 100% the same. I > personally think it's much easier to work with as well. The major changes: > > - Bazel. Scons began to annoy me beyond belief so I took the leap and > gave Bazel a try. I'm glad I did. It's fast and reliable (although initial > startup can be a little slow) and it has great support for > cross-compilation. (See https://github.com/mobileink/bazel-crosscompile > for more info on cross-compiling). OpenOCF supports cross-compiling > from macOS and Linux to Raspberry Pi 3B and Android; support for other > targets should be pretty easy to add. > - C without headers. This is the ridiculous bit. I came across > makeheaders <https://www.hwaci.com/sw/mkhdr/> a few weeks ago. It's a > wonderful little program by none other than D. Richard Hipp of Sqlite > renown, that analyzes C source code and generates the corresponding headers > - one per source file, containing exactly what it needs, no more and no > less. So you will notice that OpenOCF contains no headers (it does contain > some .h files but they are only used by makeheaders and are not included by > any source files.). Since the organization of the code was beginning to > annoy me even more than Scons, I decided to give it a try. Having worked > with the code in this form for a couple of weeks I am more and more > persuaded that this style of coding is Sublime, not Ridiculous. For one > thing, it makes it trivially easy to refactor and reorganize your code. > Move stuff around at will, makeheaders will always ensure the headers are > right. You'll see that I've gone to town with the reorg; I think the result > is that the codebase is much easier to see and understand. I expect to do > more of this, incrementally, where it helps make the code clearer. > > The code corresponds to Iotivity 1.3.0; I'll upgrade as new versions are > released. Tested on Mac, Linux, Windows, Raspberry Pi 3B. Alas there is > only one demo program at the moment, https://github.com/ > OpenOCF/iochibity/tree/master/examples/discovery. Work on others is under > way. > > Java and Android support is implemented via a separate library, > https://github.com/OpenOCF/iochibity-java. This was working a few weeks > ago but then my phone broke. In the meantime I've made many changes and > have not gotten back to Android so it may not work. I'm supposed to get a > new phone today, though, and firming up Java/Android support is my top > priority. > > I'm not crazy enough to think that Iotivity will want to follow my lead > regarding Bazel and makeheaders, but there are a few bits of OpenOCF that > may be attractive to Iotivity devs. Specifically, some improvements to the > logging system, and some refactoring for portabillity. For logging I've > added (preliminary) support for hooking in a file descriptor so logging can > go to a file (need this for an ncurses-based browser I'm building), and for > logging long strings (e.g. JSON representation of payloads). As for > refactoring, see https://github.com/OpenOCF/iochibity/tree/master/ > src/comm/transport/udpip, which should be fairly self-explanatory. > > I hope you have fun with it. Feedback (and patches) always welcome. > > Gregg > > _______________________________________________ > iotivity-dev mailing list > [email protected] > https://lists.iotivity.org/mailman/listinfo/iotivity-dev > >
_______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
