Re: cleaning and surprises

Mats,

If your SConscripts are doing a lot of miscellaneous python logic which
create those files and/or use Execute(), then that an issue with your build
setup.
If SCons is doing that, I'd be quite surprised with the exception of any
configure context files.

-Bill

On Fri, Sep 21, 2018 at 1:41 PM Mats Wichmann <[email protected]> wrote:

>
> 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?
> _______________________________________________
> Scons-users mailing list
> [email protected]
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users