Change no-exec to show (partial) list of targets to build.

[bdbaddog]

This issue was originally created at: 2004-10-03 14:12:32.
This issue was reported by: kquick.

kquick said at 2004-10-03 14:12:32

If the --no-exec (or related) flags are used to request that scons not actually perform build actions, the output should not show explicit build instructions, for the following reasons:

1. SCons uses dynamic scanning of files to determine their dependencies; files that would be (re)built during an actual build cannot be scanned if that build operation does not occur. This means that some source dependencies of these files might not be detected. If those source files must also be built, then those operations would not be detected and shown and therefore the list of build operations may be incomplete.
2. Another effect of the above dependency scanning misses is that dependencies will not be properly detected, and so targets would be shown as being built out of sequence.
3. Some build actions might modify the build environment (e.g. setting construction variables such as CCFLAGS); if these actions are not actually executed, then the echoed build action for subsequent builds will be incorrect.

The option-n-wrong.py file attached to this patch will demonstrate these issues when run against a current scons. [This file is separated from the actual patch because it is not valid either before or after the patch; the patch takes a different approach to solving the problem and therefore this test is included separately as information regarding the problem only.]

On the general principle that it's better to show no information than wrong information, the --no-exec operation of SCons is changed to simply show the names of targets that would probably be rebuilt on an actual build, and to notify the user that this is not a complete list of targets.

More specifically, the following behavior occurs when one of the --no-exec flags is used for the scons invocation:

• For File Node targets that would be built, output: build: <target>
• For Dir Node targets that would be built, output: build dir: <targetdir>
• The above may be followed by (cached) if the target has been detected as existing in the cache; note that the target may not actually be retrieved from the cache during an actual build due to a changed signature from issues 1), 2), and 3) above.
• For File Node targets that would be removed for a --clean invocation, output: remove: <target>
• For actions with no targets, nothing is shown. This can usually (always?) only occur with an Environment.Execute() or an ActionFactory() type of operation.
  • Instead of showing nothing, and alternative would be to actually show the strfunction() results, prefixed by noexec: . However, this would require special handling for ListAction handling, which usually only causes output for the first action in its list for --no-exec invocations to suppress duplicate listings of the same target. This option was not chosen.
  • Various tests in the test/ directory that use Execute() or ActionFactory() with --no-exec have been updated to remove this output information; this is not entirely satisfactory, but occurs only on --no-exec operations.

stevenknight said at 2004-10-23 11:43:28

Hey Kevin--

Boy, I don't know about this one. I see your point that there are situations where we can't show exactly what will happen if a file that needs scanning is generated, but people are really used to the -n option (from Make) showing the commands that will be executed, and it's very useful information the vast majority of the time. People usually use -n to get some idea of what will happen--what commands will get run--not just what targets will get updated. With this in mind, saying absolutely nothing about an Execute() action is especially suspect.

I could see adding this functionality as an additional option, but I don't think we can change the behavior of -n this drastically without causing a lot of uproar. I think it does make sense to make the limitations w.r.t generated files very prominent in the documentation, though.

Comments?

    --SK

stevenknight said at 2004-12-02 13:30:39

This would be a really significant change interface change. Kevin submitted this patch because we can't be sure, when using -n, that the commands we display will really be what will be executed, because specific commands may generate files that will be scanned, which may affect what other files will need to be generated, or what specific commands will look like. I see the point, but the solution in this patch would be to genericize everything when -n is used to just build: <target> and build dir: <targetdir>. That loses too much information for me. Even if it's not perfect, the current output is tremendously useful, especially in the common, less complicated situations where there aren't a lot of generated files and the like. It's also behavior that people expect from the way Make handles -n. I'm inclined to deal with the issue just be adding documentation to the -n section of the man page and User's Guide describing the limitations of -n. Comments?

issues@scons said at 2004-12-02 13:30:39

Converted from SourceForge tracker item 1039589

stevenknight said at 2006-05-26 04:06:02

Created an attachment (id=15)
Patch, copied from SourceForge tracker.

stevenknight said at 2006-05-26 04:06:56

Created an attachment (id=16)

Test case, copied form SourceForge tracker.

stevenknight said at 2009-02-22 09:07:51

Bug party triage: reprioritize the idea of a separate option for this behavior. Since no one else seems to be asking for this, make the issue lower priority. Someone with an appropriate itch to scratch can tackle it sooner if they wish.

stevenknight attached noexec_list.patch at 2008-03-25 11:08:15.

Patch, copied from SourceForge tracker.

stevenknight attached option-n-wrong.py at 2008-03-25 11:08:15.

Test case, copied from SourceForge tracker.

[mwichmann]

Hmmm, I detest the way no-exec and clean work - where they lie and/or do work that is not expected (many sconscripts are written such that things are built when you clean - maybe we should better document how to avoid that), but this drew a pretty negative reaction back in 2004. Is it worth keeping open?