I've asked a lot of questions about scons usage (some of which even got
good answers :) )... sorry. Here's one more set as we're inching closer
to being able to propose some changes, with a some of the baseline
"follow coding standards" reformatting merged and hopefully the others
not too far away.
First a simple question:
there are two copies of a tool -
tools/scons/UnpackAll.py
build_common/tools/UnpackAll.py
They seem to both be used, the build_common one thus:
build_common/external_builders.scons:SConscript('tools/UnpackAll.py')
extlibs/android/sdk/SConscript:SConscript('#build_common/tools/UnpackAll.py')
extlibs/arduino/SConscript:SConscript('#build_common/tools/UnpackAll.py')
And the top-level-tools one thus:
extlibs/boost/SConscript: boost_env.Tool('UnpackAll',
toolpath=['../../tools/scons'])
They clearly have a common ancestor, should we smash this down to just
one copy of the tool?
====
Second a question that takes a few more words to describe:
build_common/iotivityconfig contains some stuff that tries to sense the
host's environment.
An older patch proposed moving this stuff to a place it's more naturally
(almost automatically) picked up by scons, though it never got any real
traction
https://gerrit.iotivity.org/gerrit/8597
I think putting tools written in python in the right place is a fine
idea, but before moving this stuff, let's look at it:
there's code there that looks for compiler details, etc, but it doesn't
look like any of it except a pthreads check is used:
(from build_common/SConscript)
######################################################################
# Check for PThreads support
######################################################################
import iotivityconfig
from iotivityconfig import *
conf = Configure(env,
custom_tests =
{
'CheckPThreadsSupport' : iotivityconfig.check_pthreads
} )
# Identify whether we have pthreads support, which is necessary for
# threading and mutexes. This will set the environment variable
# POSIX_SUPPORTED, 1 if it is supported, 0 otherwise
conf.CheckPThreadsSupport()
env = conf.Finish()
The test for this itself is a configure-style attempt to compile a very
small program which just checks if _POSIX_THREADS is defined.
My question is, should we drop iotivityconfig and just make a decision
based on known characteristics of known targets? We do plenty of that
kind of stuff elsewhere in the code, there's no chance we'll suddenly be
facing a platform we don't know anything about without that build
falling apart in many many other places. The pthreads test does, as a
side effect, call a check-for-gcc test also but the result is not used
and scons already knows if it's gcc or not based on its internal stuff,
so it does not serve any purpose to check that.
Does anyone left on the list know this stuff? Was it actually written
for iotivity, or just copied from somewhere else and maybe now is just a
historical artifact? Is if okay if the above is replaced by a
target-specific rule which sets POSIX_SUPPORTED=1 in the environment?