Why SCsub not SConscript?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By azurvii
:warning: Old Version Published before Godot 3 was released.

Just curious.
It’s about the SCons build files used in the source repo.

:bust_in_silhouette: Reply From: Akien

I don’t know the reason for this choice, but by googling it seems to be used only in Godot an tolua++, both of which have Ariel Manzur among their founder, so I guess it’s a personal choice of his :slight_smile:

I think it’s nice personally, as it makes it clear that the SCsub scripts can’t be used by themselves. So trying to run scons in a folder with only SCsub would likely simply return that there is no SConscript file, while if there was one, it might fail with a more misleading message?

Haha, thanks. I just gave it a try, having only SConscript also fails scons’ invocation. It looks like by default SConstruct is needed.
SConstruct and SConscript are both automatically highlighted by Qt’s editor in python syntax. I had to add SCsub to the highlighter def file to get proper colors.

azurvii | 2016-05-20 08:39

Ah I’ve noticed the lack of syntax highlighting too, that’s indeed a disagreement.

Knowing Ariel, the reason for the SCsub name is probably related to having had a sandwich at Subway’s before setting up the buildsystem :stuck_out_tongue:

Akien | 2016-05-20 09:10

:bust_in_silhouette: Reply From: punto

The style of scons scripts we use was created in 2001 for an engine we were making for an MMO which eventually became “Regnum Online”. I don’t remember if there was a specific reason, I probably just didn’t like the name “Sconscript” that was on all the documentation (it looks too much like “SConstruct”), so I used the name “SCsub” because it’s like a sub-script (or something that goes on a sub directory).

The way we use scons (which is also unusual I think, I’ve seen very few projects using scons over the years, and they all used it in a very complicated way which failed to build most of the time) remained very similar over the years, in fact it’s simpler today. We did env.Clone() a lot more, at some point we built multiple dlls, and until recently we could build multiple targets with the same command. There’s still a few things we could improve about it (for example we could put all the .o files in some hidden directory, and I wish there was an easier way to distribute scons for windows), but I’m pretty happy with how it works now (although I would like to still build multiple targets with the same command :p)