[Scons-users] usage of Glob
Mats Wichmann
mats at wichmann.us
Mon Oct 2 16:47:17 EDT 2017
scons seems to have a an almost limitless capacity for making me feel
stupid. Nine months of working rather a lot on this project, following
more than a year of digging around though on a much less intense basis,
and I'm still fighting things I don't quite understand why they work the
way they do.
One of my projects is to eliminate parts of the build which leave their
objects in the source tree, instead of building into the variant
directory. Several developers have told me this is a problem because
truly parallel builds don't work. I don't mean "scons -j8" kinds of
parallel builds, I mean several independent builds with different
options, each going to a different variant dir. This is to cut down the
"did I break anything with that change" answer time.
I've got lots of these stamped out because I understood what was
happening: developers had used Python facilities directly to obtain and
manipulate paths, thus evading the variant substitutions scons would
otherwise perform. Things like this:
src_dir = os.path.abspath(os.curdir)
not hard to get rid of.
Now I'm looking at one which doesn't make sense to me. The scenario is
an scons script that's supposed to fetch (if needed) and build an
external project from github, but at the moment instead builds it by
default from a local forked copy. It builds the list of source files by
doing a glob on the source directory.
So we have, in abbreviated form, something like this:
extlibs/libcoap/SConscript:
libcoap_src_root = src_dir +
'/resource/csdk/connectivity/lib/libcoap-4.1.1'
src_files = glob.glob(os.path.join(libcoap_src_root, '*.c'))
env.StaticLibrary('coap', libcoap_src, OBJPREFIX='libcoap_')
I'm not actually surprised this gets files built in the source tree, as
it's got a hard-coded absolute path by way of using src_dir (which is
defined globally for the project, something I'm gradually getting rid of
since scons provides a way to determine srcdir/abspath if it really is
needed), and it's using Python (glob.glob) to build the path - by the
time scons sees them in the StaticLibrary builder they're root-relative.
So I try this modification:
libcoap_src =
libcoap_env.Glob('#resource/csdk/connectivity/lib/libcoap-4.1.1/*.c',
strings=True)
libcoap = libcoap_env.StaticLibrary('coap', libcoap_src,
OBJPREFIX='libcoap_')
A bit of examination of libcoap_src shows it's pretty much what I'd
expect - the paths are non-rooted, but... builds are still happening in
the source directory. Tried it without the strings=True as well and
examined the resulting list of nodes, as well as various combinations of
paths (like using relative ../ paths instead of #-anchored paths), etc.
I've also tried adding an scons script in the resource/ directory where
the source files are and calling to it to see if "files are in the
directory the sconscript is in" makes it better, there I see the
nodes/strings coming from Glob are context-correct - they have no path
prefix from the viewpoint of that script. Doesn't help.
Any ideas what could still be defeating the variant stuff here? I
realize this may not be enough info diagnose...
Does Glob do something I'm not expecting? Something else obviously wrong?
More information about the Scons-users
mailing list