What in gcc depends on MacOs command line tools?

[zapta]

We are trying to understand why our SCons based app has dependency on macos developer tools even though we use standard python and basic commands with no reference to tools such as git or gcc.

Below is a simple example that demonstrates the issue .

Verification that developer tools are not installed

$ xcode-select -p
xcode-select: error: Unable to get active developer directory. Use `sudo xcode-select --switch path/to/Xcode.app` to set one (or see `man xcode-select`)

The SConstruct file

# Disable all default tools
env = Environment(tools=[])

# Use timestamp-only decider (no content reading)
env.Decider('timestamp-newer')

# Simple builder using touch
env.Command('output.txt', 'source.txt', 'touch $TARGET')

# Define dependency.
env.Depends('output.txt', 'source.txt')

Creating input file

echo "Hello world" > source.txt

Runnins scons

$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
xcode-select: note: No developer tools were found, requesting install.
If developer tools are located at a non-default location on disk, use `sudo xcode-select --switch path/to/Xcode.app` to specify the Xcode that you wish to use for command line developer tools, and cancel the installation dialog.
See `man xcode-select` for more details.
xcode-select: note: No developer tools were found, requesting install.
If developer tools are located at a non-default location on disk, use `sudo xcode-select --switch path/to/Xcode.app` to specify the Xcode that you wish to use for command line developer tools, and cancel the installation dialog.
See `man xcode-select` for more details.
touch output.txt
scons: done building targets.

Any idea what in SCons runtime depends on developers tools and how to avoid this dependency?

[zapta]

... I traced the examples and the issue seems to be at this point

scons/SCons/Defaults.py

Line 84 in a22182b

_default_env = SCons.Environment.Environment(*args, **kwargs)

Despite the env initialization in SConstruct with tools=[], the DefaultEnvironment() function is called with empty args and kwargs, and initializes with with reference to the standard tools. adding in line 84 the arg tools=[] fixed the problem.

With that in mind, my new question is what do I need to do in SConstruct to avoid that env initialization with reference to the default tools which triggers a dialog box on MacOS.

[mwichmann]

... I traced the examples and the issue seems to be at this point

scons/SCons/Defaults.py

Line 84 in a22182b

_default_env = SCons.Environment.Environment(*args, **kwargs)

Despite the env initialization in SConstruct with tools=[], the DefaultEnvironment() function is called with empty args and kwargs, and initializes with with reference to the standard tools. adding in line 84 the arg tools=[] fixed the problem.

With that in mind, my new question is what do I need to do in SConstruct to avoid that env initialization with reference to the default tools which triggers a dialog box on MacOS.

By way of a bit of explanation, the Default Environment is accessed internally even if you didn't do anything that looks like it would use it, to fish out some settings to use if nobody otherwise supplies them. This means it gets silently instantiated during startup. This is possibly not the greatest design decision - it would be nice if one could access these "default defaults" without having to go through the heavyweight environment instantiation, trying a bunch of tools to guess at the right setup for the platform, but that wouldn't be a trivial bit of rework. The current workaround is if you don't need any Builders from the default env, then force-instantiate the default environment with an empty tools list like @bdbaddog describes - we do that a bunch in the test suite to avoid the overhead of instantiating the full set of platform tools when that's not needed.

The message itself isn't from SCons - we try to call a compiler to ask its version to determine both existence and in some cases for the actual version number. If it fails, SCons assumes "don't try to use that one" and proceeds. Macos just chooses to be chatty/helpful about that, and you see the result in the output - but it didn't affect SCons actually running the build.

The slightly scary thing is MacOS seems to have now extended this complaint to the system Python as well - I see on the internet that people have seen the message typing "python3' at a terminal, at least in Tahoe. Usually better to install a separate Python.

One other comment. You have this:

# Define dependency.
env.Depends('output.txt', 'source.txt')

You neither need nor want that - the dependency is established by the builder call (env.Command), which already is telling SCons that the target depends on the source(s).

[zapta]

Ok, this SConstruct seems to work.

# Disable all default tools
#env = Environment(tools=[])
env = DefaultEnvironment(tools=[])

# Use timestamp-only decider (no content reading)
env.Decider('timestamp-newer')

# Simple builder using touch
env.Command('output.txt', 'source.txt', 'touch $TARGET')

# Define dependency.
env.Depends('output.txt', 'source.txt')

[bdbaddog]

Don't do this env = DefaultEnvironment(tools=[])

You just need to tell DefaultEnvironment() not to initialize any tools, then create your own new Environment()

so

# Disable all default tools
DefaultEnvironment(tools=[])
env = Environment(tools=[])

# Use timestamp-only decider (no content reading)
env.Decider('timestamp-newer')

# Simple builder using touch
env.Command('output.txt', 'source.txt', 'touch $TARGET')

# YOU DON"T NEED THIS, the Command above establishes this dependency 
# Define dependency.
# env.Depends('output.txt', 'source.txt')