I'm a little confused by the amount of "autoconf" stuff that happens in
the SCons scripts, some of which doesn't seem to be configure style
behavior at all, like this one:

gtest_env.Configure(gtest_dir, 'cp libgtest.a lib')

that looks a lot more like a build instruction than a configure one.

possibly part of the confusion is there is scons's own Configure, and
then we add a method in external_builders.scons which also ends up named
Configure:

env.AddMethod(__configure, "Configure")

that seems like a recipe for confusion... at least, it is confusing me.
Be cool if someone (George - are you the resident expert?) could explain.

One very specific question:

there's a whole iotivityconfig directory with python modules in it,
which apparently used to do a fair bit of compiler detection work.  Now
it looks like it wants to check whether there is POSIX thread
support, though the way this iotivityconfig module is imported it looks
like the other tests get run too (based on config.log), even if it
doesn't seem anything is done with the other results.

Is there any reason to continue configure-checking for pthreads support?
 Can't we just use what we know about the different platforms, just like
so many other decisions are wired in on this basis?  The presence of
this check is step 1 behind blocking a bug I filed, IOT-2356.

-- mats

Reply via email to