Build extlibs libs straight to destination 57/26157/9
authorMats Wichmann <mats@linux.com>
Wed, 4 Jul 2018 20:17:05 +0000 (14:17 -0600)
committerMats Wichmann <mats@linux.com>
Thu, 23 Aug 2018 13:36:26 +0000 (13:36 +0000)
commit892950876113f137bb5f80fa60373e44a5a9cf84
treef67b0139ee8f558290b7bf704b1e214b3ff7f23d
parent9b7ff9ad05094d5a5b91a7bebc1c4cf5999751ed
Build extlibs libs straight to destination

As described in IOT-1986, Windows builders (in particular) have occasional
problems with multi-process builds - that is -j with a number larger
than one.  Libraries are built with a {Static,Shared}Library() call which
builds in the directory where the SConscript is executing, following
which we "install" into the top-level directory, where link instructions
will find them (the top dir is always in LIBPATH), and where tests and
other binaries expect to find them. For example, from these instructions:

  static_libmbedx509 = mbex509_env.StaticLibrary('mbedx509', mbeX509_src)
  mbex509_env.InstallTarget(static_libmbedx509, 'mbedx509')

For that, we see this abridged sequence from a Linux build log:

  scons: building `extlibs/mbedtls/libmbedx509.a' because it doesn't exist
  Preparing target extlibs/mbedtls/libmbedx509.a...
  Building extlibs/mbedtls/libmbedx509.a with action:
    $AR $ARFLAGS $TARGET $SOURCES
  Building extlibs/mbedtls/libmbedx509.a with action:
    $RANLIB $RANLIBFLAGS $TARGET
  ranlib extlibs/mbedtls/libmbedx509.a
  scons: building `out/linux/x86_64/debug/libmbedx509.a' because it doesn't exist
  Preparing target out/linux/x86_64/debug/libmbedx509.a...
  Building out/linux/x86_64/debug/libmbedx509.a with action:
    Copy("$TARGET", "$SOURCE")
  Copy("out/linux/x86_64/debug/libmbedx509.a", "extlibs/mbedtls/libmbedx509.a")

The actual target that matters for dependency computation is the result
of the library build, and that target is "done" when the StaticLibrary
call is complete, so other processes which depend on that target can be
released by the SCons Taskmaster to run at that point.  File copies are
not necessarily atomic on Windows Python, and worse, the build-plus-copy
is certainly not atomic, so sometimes one of the released processes
finds the "installed" library is not there (yet) when it tries to
link to it.

At least one of the sconscripts in extlibs has tried to mitigate this
problem by not doing the InstallTarget(), and instead pointing clients
of the library right to the directory it is built in by adding to the
LIBPATH construction variable. This is also done for a couple of libs in
build_common/windows/SConscript. This change is the other side of the same
coin - instead of pointing builds to a bunch of places where a library was
built, just build straight into the location where we want the library,
still avoiding the copy step.  In other words, instead of saying:

  StaticLibrary(target='foo', source=foo_src)
  env.AppendUniqe(LIBPATH, this-dir)

we can say:

  StaticLibrary(target='<somepath>/foo', source=foo_src)

Sorry for the long message - the upshot is, to test this idea, start
by converting the extlibs libraries to build straight into the place we
want them; if it works out, convert the others later.

Change-Id: I81858f221a2e0a0ee913dcd452fc607fcf79e7b2
Signed-off-by: Mats Wichmann <mats@linux.com>
Bug: https://jira.iotivity.org/browse/IOT-1986
extlibs/cjson/SConscript
extlibs/gtest/SConscript
extlibs/libcoap/SConscript
extlibs/mbedtls/SConscript
extlibs/sqlite3/SConscript
extlibs/yaml/SConscript