[Scons-users] Provide default Import to SConscript

[Hua Yanghao]

On Sun, Feb 18, 2018 at 12:17 AM, Bill Deegan <bill at baddogconsulting.com> wrote:
> Hua,
>
> From the tree you've shared, I'm going to guess you have way more
> SConscripts than you need.
>
> For example, you're set of test directories could have a single SConscript
> instead of one per.
> Which no doubt are just a few lines each.

I think this is doable, however then I need to abstract on a different level.
For example, each and every one of the module can be separately
enabled/disabled,
And I am really trying to use the Kbuild/Makefile way of doing this:
by simply enable
the directory that has the SConscript file in a top level config file.

If I do use a single SConscript file to handle a lot more individually
independent module
I could have just end up doing everything in the top level SConstruct
as well, or ending
up with Spencer's solution to have a separate set of module level
configuration file that
is completely un-related to scons (not very good for promoting scons).


> In some cases it looks like you have a SConscript in a directory which only
> has a header file (or none) and then a directory (or more) of source code.
> Skip the SConscript in the basically no-op directorie(s).

This is intended, as I do not want to expose all include files un-conditionally,
to make sure if a module (even if only consists of only header files,
for example uthash library)
is disabled nothing get included in the build process.

> Another suggestion, use variant dirs so you're not creating build files in
> your source directory.

I am using variant_dir and the tree is from the build directory, it is
just I didn't disable the hard linking
in the build directory. this is the default scons behavior.

> If you find yourself with a ton of very small SConscripts, it's a sign that
> you may be doing something non-scons'ian.
>
> Of course it also depends on how working on each group of code is split up
> between different developers.
>
> There is some art in structuring your build system (and your code) such that
> engineers rarely end up causing merge conflicts with each other.

The only state of the art building system I admire is the kbuild
system. If all those small
makefiles in the kbuild system is considered non-scons'ian, I have to
say non-scons'ian
will be my intention. ;-)

> I can see some value in default_import, but it would be something requiring
> some debate on getting accepted.
> As far as I can recall, your's is the first request for something like this
> in the history of SCons (or at least as long as I've been involved).

I am looking forward to more opinions on this and I will personally
starts looking into
the guts and see what I can help here.

> Philosophically SCons is about being explicit in the build requirements and
> also about being correct by design.  Yielding reproducible builds regardless
> of the individual developers shell and machine setup.

Yes, and this is why me and many others loves scons.
But this doesn't prevent from scons to getting even better.

Cheers,
Yanghao