1134633 - convert makefile rules with props2arrays.py to use moz.build GENERATED_FILES

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Nathan Froyd [:froydnj]]

Now that GENERATED_FILES can generate makefile rules for generating
files, we can start moving rules from Makefile.in's into moz.build.

Comment 1

[Nathan Froyd [:froydnj]]

Attachment: convert makefile rules with props2arrays.py to use moz.build GENERATED_FILES

These are pretty straightforward; I converted things to a loop in
dom/encoding/, but I can be convinced to write it all out longhand if you think
that's clearer.

Comment 2

[Nathan Froyd [:froydnj]]

Attachment: convert makefile rules with props2arrays.py to use moz.build GENERATED_FILES

Now that GENERATED_FILES can generate makefile rules for generating
files, we can start moving rules from Makefile.in's into moz.build.

Sigh, it works better when we update props2arrays.py to conform to the new
moz.build world.

Comment 3

[Michael Shal [:mshal]]

Comment on attachment 8566537 [details] [diff] [review]
convert makefile rules with props2arrays.py to use moz.build GENERATED_FILES

>-GENERATED_FILES += [
>-    'domainsfallbacks.properties.h',
>-    'encodingsgroups.properties.h',
>-    'labelsencodings.properties.h',
>-    'localesfallbacks.properties.h',
>-    'nonparticipatingdomains.properties.h',
>-]

>+
>+for prefix in ('domainsfallbacks', 'encodingsgroups', 'labelsencodings',
>+               'localesfallbacks', 'nonparticipatingdomains'):

Do we expect this list to change much going forward? If so I'd recommend a one-per-line style, similar to the removed GENERATED_FILES variable above for easier diffing when they're added/removed. (Maybe use a local "prefixes" variable if it's too ugly in the for statement).

>+    GENERATED_FILES += [header]
>+    props = GENERATED_FILES[header]

Is there some python magic we could do to skip the seemingly redundant GENERATED_FILES += [header] step? Ie: just have the header get automatically added to GENERATED_FILES in __getitem__ or whatever. I don't want to block on this, though. Or if it's a bad idea for other reasons, that's fine too.

>+wincharset = GENERATED_FILES['wincharset.properties.h'

I expect you'll need a ] here :)

Comment 4

[Nathan Froyd [:froydnj]]

(In reply to Michael Shal [:mshal] from comment #3)
> >+for prefix in ('domainsfallbacks', 'encodingsgroups', 'labelsencodings',
> >+               'localesfallbacks', 'nonparticipatingdomains'):
> 
> Do we expect this list to change much going forward? If so I'd recommend a
> one-per-line style, similar to the removed GENERATED_FILES variable above
> for easier diffing when they're added/removed. (Maybe use a local "prefixes"
> variable if it's too ugly in the for statement).

I don't know how much we expect this to change, but the separate |prefixes| variable is a good idea regardless.

> >+    GENERATED_FILES += [header]
> >+    props = GENERATED_FILES[header]
> 
> Is there some python magic we could do to skip the seemingly redundant
> GENERATED_FILES += [header] step? Ie: just have the header get automatically
> added to GENERATED_FILES in __getitem__ or whatever. I don't want to block
> on this, though. Or if it's a bad idea for other reasons, that's fine too.

That seems reasonable; I'll file a followup bug for brainstorming.  I think I'd avoid __getitem__ magic and instead want |GENERATED_FILES.add('x')|.

> >+wincharset = GENERATED_FILES['wincharset.properties.h'
> 
> I expect you'll need a ] here :)

Indeed. :)

Comment 5

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

https://hg.mozilla.org/mozilla-central/rev/0645b0eeb720