Hi, Patch https://gerrit.iotivity.org/gerrit/#/c/8597/ is a first cut proof of concept. Here are some more thoughts on improving the structure of the build system. We have:
- tools, which are always designed with some more-or-less specific use patterns in mind. They should be used accordingly; that's the motivation for adopting site_scons etc. - conventions. there may not be any universal, non-controversial conventions, but there are conventions, and the more closely a project hews to convention the less alienating it is to newcomers, broadly speaking. For example, most projects have a doc/ directory, and that's where you go to find documentation. - conceptual structure. a build system always involves at least two elements: configuring the build environment/context, and building within that environment. code that configures the build environment should not be in the source tree. Currently Iotivity violates this principle to some extent; for example, we have not one but two files called third_party_libs.scons, both in the source tree, neither of which have much directly to do with building the code. That kind of functionality can be migrated to e.g. site_scons and site_scons/site_tools. - aesthetics. overlaps with conceptual structure. For example, build_common/ is misnamed; it contains precisely what is not common across builds. Personally I think it should be renamed "hosts/"; that's not solely a matter of taste, its also about conceptual transparency. In any case its name should reflect its function. Conceptually, the source tree should contain only source code, plus build scripts specific to the directories that contain them. Code that configures the build environment should live outside of the source trees, in site_scons and maybe hosts/ (build_common/). Currently the SConscript files contain a bunch of stuff that belongs in build (as opposed to product) config files. For example, setting language mode (c99, c11, etc), warning flags like -Wall, etc. can be set once and for all during build environment configuration. Here are some files that should be migrated out of the source trees: third_party_libs.scons, resource/unit_tests.scons, resource/csdk/arduinodue.properties and arduinomega.properties, etc. Documentation: Currently there is a lot of documentation buried in the source trees. For example, resource/csdk/security/README-building-and-running-secure-IoTivity-stack.txt. That kind of stuff should go in a top-level doc/ directory. There's no point (IMO) in keeping it with the source code. It just makes it harder to find. Developers should not have to scour the source tree in order to discover documentation. E.g. "Gee, I wonder if there's some doc on provisioning. Let's see, where is that located in the source tree? I forget, I'll have to waste some time groping about till I find it. Gee there's nothing there." How am I supposed to know that the doc is buried in the examples subdir - or that there are in fact two provisioning directories? The tools/ directory can be removed. Everything it contains can be migrated to a more appropriate location - python/scons files to site_scons, shell scripts to bin/, etc. Of course the SConsript files themselves can be improved, but that's a separate issue. Cheers, Gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160612/c5dfcc32/attachment.html>
