Please note:The SCons wiki is in read-only mode due to ongoing spam/DoS issues. Also, new account creation is currently disabled. We are looking into alternative wiki hosts.

Better Error Messages

This is a draft. Feel free to edit. If you have questions, please pose them on the mailing list.

It is believed Bug#863, Bug#1437, Bug#1442, Bug#1871, and Bug#1895 are exemplars of this problem.

The Problem(s)

There are two ways that a missing Builder can be observed by a user:

Currently, both cases generate opaque error messages (or worse, no error message and appear to work). The objective is that both cases should generate descriptive error messages.

Another related difficulty with the current scheme is that full toolchains are not deduced. That is, if a user adds a Builder that converts .xyz to .c then it requires extra steps so that SCons will be able to turn this into a .o. And if it's not set up correctly, the error message is opaque about what went wrong.

A somewhat-related difficulty to the previous point is the use of non-standard suffixes. A user might wish to use the suffix .cplusplus on a C++ file for legacy reasons, yet adding this suffix is painful (or not possible?). (It should also be possible to remove suffixes.)

Analysis

From the user's perspective, SCons should act as if all Builders were present at all times, but only Builders configured into a specific Environment are in play. That is, SCons should always be able to determine that a Builder should be used (if not always which one), and only generate an error if the required Builder isn't configured.

This implies that the process of setting up the toolchains should be separate from the actual configuration of a Builder. The toolchain information (the relationship between source and target suffixes and the Builder name) should always be established, while the Builder itself would only be configured if the circumstances warrant (i.e., if the command exists for a default builder or if the Builder is explicitly configured).

Implications

The implications are twofold:

The problem is how to get there from here.

Possible Strategy

There's one possible strategy that SCons could employ:

I'm not sure that this is the best strategy (it seems to have a lot of overhead), but it shows that there is at least one strategy that will deal with the difficulties.


Still open:

BetterErrorMessages (last edited 2009-02-08 00:12:18 by ip68-7-77-81)