On Fri, Jun 24, 2016, at 01:58 PM, Mats Wichmann wrote: > On 06/24/2016 02:51 PM, Dave Thaler via iotivity-dev wrote: > > Let me just add that when we started from the existing iotivity code base > > it became clear how bad the platform support in iotivity was > > compared to most open source projects (e.g., that use config.h based > > feature checks) including the extlibs that iotivity depends on. > > In the windows-port branch we have been trying to clean that up one step at > > a time by making iotivity more like how projects are supposed to be. > > It?s not all the way there yet (we used platform_features.h as an interim > > step towards config.h), but I would hate to see changes that make iotivity > > move away from that, and I?m happy to help contribute to it since iotivity > > is really painful to use right now. > > I know many of us are used to configure-style checks, but they're > notoriously a pain for cross-building, as they tend to be hard to > unconvince to make choices based on host, rather than target (a battle > we've had even with this setup at least targeting Tizen). Just so that's > kept in mind. > > Also, I thought I heard somewhere that the awkward extlibs existed to > emphasize that these external projects were under different licenses. >
I've also seen problems with various config solutions, etc. However, the vast majority of them can be addressed by having an explicit strategy and conventions. One thing I've worked up locally and need to get updated for submission is generation via SCons. We have at least one location that has a generated config.h checked in that causes headaches for different platforms. I'd worked up SCons based generation of it, including env hashed checks to update when needed. It definitely sounds like time to get that up -- Jon A. Cruz jon at joncruz.org
