User Tools

Site Tools


tizen

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
tizen [2018/02/09 13:12]
Phil Coval
tizen [2018/07/12 23:13] (current)
Mats Wichmann
Line 875: Line 875:
  
 {{http://​www.tizenexperts.com/​wp-content/​uploads/​2015/​03/​SAM_0875.jpg}} {{http://​www.tizenexperts.com/​wp-content/​uploads/​2015/​03/​SAM_0875.jpg}}
 +
 +
 +=== Tizen Build Details / Gotchas ===
 +
 +This is here to have it recorded someplace, should move somewhere else.
 +
 +The tizen build as done by auto_build.py is quite confusing. ​ First it calls the top-level gbsbuild.sh script, which provisions a build environment,​ making sure the rpm specfile which is in git as tools/​tizen/​iotivity.spec is in a place it can be found. ​ gbsbuild.sh then calls "gbs build",​ which launches an rpm build using the specfile. That build calls scons. ​ That part of the build is relatively normal, things are heirarchically in the places you'd expect, but there is still an issue (noted after the next paragraph).
 +
 +Then there are two more calls, this time directly to a subsidiary sconscript several levels deep in the tree.  These each construct a call to gbsbuild.sh,​ which provisions a tree - differently - which then calls gbs which calls rpmbuild which calls back into scons. ​ These latter two builds have top-level scripts (SConstruct files) which their gbsbuild.sh copied in from somewhere else, so these two do not use the standard build at all. Since they don't intend to build the whole tree - they are for examples - they also don't fully provision.
 +
 +In all cases, gbsbuild is called with arguments relating to the options available for a normal iotivity build which are handled in a way such that they are supposed to eventually make it to the scons instance which does the building. They are interpreted in numerical order only so gbsbuild and the matching specfile have to be changed in sync, and all gbsbuild.sh files are far from matching the current iotvity option set, which is defined in git in build_common/​SConscript. Changing details of iotivity build arguments are almost certain to end up causing surprises in the tizen secondary builds. ​ The two later builds also don't pick up the standard tizen script which sets options, so if you think you are setting a new option in build_common/​tizen/​SConscript,​ that will apply only to some of the build, and the build will in fact probably fail in surprising looking ways.
 +
 +
 +
 +All of this has unpleasant side effects.
tizen.1518181963.txt.gz ยท Last modified: 2018/02/09 13:12 by Phil Coval