Does the tizen build have a maintainer any longer?
I'm finding it utterly unmaintainable due to the convoluted nature of the build (*). Most improvements I test to the overall build system trip over the fact that tizen doesn't see them. I'm not talking about major overhauls here, this appears in things like: "put the C++ build flags into each target-specific build script, and not in individual code build scripts". Tizen uses gcc, so the flag we want here is "-std=c++11" (iotivity definitely requires C++11 support). So, instead of a random script like, say, service/scene-manager/SConscript defining "-std=c++11" (along with about 70 others), put it in build_common/tizen/SConscript. And build_common/linux/SConscript. And so on. But if you put it there, the tizen CI build doesn't see it, because some of the multiple times scons is called have not pre-provisioned their build area with the same setup as the source tree so they never read that script (and, if you want to cast blame more widely, scons doesn't consider the missing script an error, just a warning. scons upstream will probably fix this... BUT tizen is apparently forever bound to a frozen binary rpm of scons 2.1.0, now almost 7 years old, so that change won't help anything). At this point, I'm ready to propose we drop the tizen CI build unless a maintainer is willing to help fix this mess. I'm unable fix stuff that should be generic, and actually would help the other builds be more clean and easy to support, but are blocked by Jenkins not able to pass the tizen build. The tizen build doesn't behave like any other. I'm not prepared to waste any more of my (volunteer) time on fighting it. -- mats (build maintainer) (* footnote) convoluted == the build script calls a shell script, which copies some things and moves some around, which then calls gbs, which calls rpmbuild, which uses a specfile which contains instructions to call scons to do the build. then three more times, the build script calls scons which constructs a command to call a gbs setup script, each of which copies different things to different places than the first setup script, and then calls gbs which calls rpmbuild, each with a unique rpm scecfile, which calls scons with arguments that don't seem to match what anyone else's build of iotivity does these days. So for these three cases, we actually have recursive scons calls, but they're not able to accurately share build environments. I'm claiming "convoluted" is a fair statement here. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9771): https://lists.iotivity.org/g/iotivity-dev/message/9771 Mute This Topic: https://lists.iotivity.org/mt/23405346/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
