1136383 - enable specifying method names for GENERATED_FILES scripts

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Nathan Froyd [:froydnj]]

The inputs to scripts for GENERATED_FILES are restricted to filenames
only.  We have several examples in the tree, however, where a script
takes non-filename arguments.  For converting those cases to use
GENERATED_FILES, we first need to provide some way of "injecting"
non-filename arguments into the script.

This commit adds a method for doing that, by extending the .script flag
on GENERATED_FILES to include an optional method name:

  f = GENERATED_FILES['foo']
  f.script = 'script.py:make_foo'

will invoke the make_foo function found in script.py instead of the
function named main.

Comment 1

[Nathan Froyd [:froydnj]]

Attachment: enable specifying method names for GENERATED_FILES scripts

It occurs to me that it might be better to specify the method name as an
additional flag on the GENERATED_FILES entry, rather than doing some string
parsing in the frontend.  Meh, I'll let you decide.

Comment 2

[Gregory Szorc [:gps]]

Comment on attachment 8568791 [details] [diff] [review]
enable specifying method names for GENERATED_FILES scripts

Review of attachment 8568791 [details] [diff] [review]:
-----------------------------------------------------------------

The "script.py:method" convention is used in many common Python programs, including pdb and unittest/nose. It is acceptable to import this convention into moz.build.

In case you haven't been following, you may be interested in the sub-context work in bug 1134072 and bug 1132771. Any self-contained and semi-complex data structure is a good candidate for moving to sub-contexts. I would say GENERATED_FILES qualifies.

Comment 3

[Nathan Froyd [:froydnj]]

Landed with a small fix to recursivemake tests to handle the newly-passed method name, and a slight tweak to the test to ensure default and non-default method names are handled correctly:

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/fab243c8d0c5

Comment 4

[Carsten Book [:Tomcat]]

backed out for bustage like https://treeherder.mozilla.org/logviewer.html#?job_id=6967062&repo=mozilla-inbound on Windows platform

Comment 5

[Nathan Froyd [:froydnj]]

Better check for when we need to split on colons to handle win32 paths correctly + test:

https://hg.mozilla.org/integration/mozilla-inbound/rev/4314d56097d7

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/4314d56097d7