[Scons-users] cleaning and surprises

[Mats Wichmann]

In general, software tools should not "surprise" you.

In the big project I've been working on, one of the surprises is how
much work happens when you really didn't ask to do much work.  Like the
"clean" operation... yes it's easy to agree, after you think about it,
that you have to do enough work to figure out what targets have been (or
could be) built so you know what to remove.  In many build systems
that's quite explicit - the information is in the scripts and the tool
just removes that and doesn't do a lot of calculation.  But as I say, I
get surprised by how much does happen in our build.  I know that this is
the result of errors (rather, bad assumptions) by the authors of the
various bits of this setup, but these are smart developers and somehow
it doesn't come clear how to set things up.  To be a little less obtuse:

- configure checks get run
  Checking for C++ header file arpa/inet.h... yes
  Checking for C++ header file fcntl.h... yes
  ...

- external-library stuff gets run, sometimes many times:
  Checking for C++ library boost_thread... yes
  Checking for C++ library boost_system... yes

and in the end, there's been a flood of output, and some files in the
variant directory - which for the sake of amusement is completely
removed before running the clean operation - has ended up with some
/built/ files!!! So it's not that they were missed by the clean, they
were actually built during the clean process (remember, started
completely empty).

out/linux/x86_64/release/liblogger.a
out/linux/x86_64/release/libc_common.a
out/linux/x86_64/release/resource/csdk/logger/liblogger.a
out/linux/x86_64/release/resource/csdk/logger/src/logger.o
out/linux/x86_64/release/resource/csdk/logger/src/trace.o
... 13 more in current setup

It's not that this makes builds not work, but it tells me something just
isn't right in the script setup.

In fact the same thing happens in an even less work-expected situation,
asking for help.  We also had a bit of this discussion recently on list
over dry-run invocations, another "surprise".


Do we have documentation in scons of "things not to do" that could be
helpful in avoiding falling into these kinds of traps?


Note:

Even scons itself has a bit of this:

$ scons -c
scons: Reading SConscript files ...
Mkdir("/home/mats/Work/scons/build/doc/design")
Mkdir("/home/mats/Work/scons/build/doc/design/titlepage")
Mkdir("/home/mats/Work/scons/build/doc/user")
Mkdir("/home/mats/Work/scons/build/doc/user/titlepage")
Mkdir("/home/mats/Work/scons/build/doc/reference")
Mkdir("/home/mats/Work/scons/build/doc/reference/titlepage")
Mkdir("/home/mats/Work/scons/build/doc/man")
Mkdir("/home/mats/Work/scons/build/doc/man/titlepage")
scons: done reading SConscript files.
scons: Cleaning targets ...
scons: done cleaning targets.

and, not in the messages, those directories were populated, so after
starting with a clean git checkout - no "build" directory at all -
"scons -c" leaves me with a build directory with 113 files (.xml, .xsl,
SConstruct, and a few others). did cleaning really need to create
directories and populate them?


any thoughts on how to make this less surprising?  or should I just suck
it up and treat this as normal?