925350 - Remove dumbmake

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Gregory Szorc [:gps]]

dumbmake was a nice stop gap. Once the "binaries" target works, dumbmake likely doesn't need to exist any more.

Filing this bug now so it is on the radar and we can track dumbmake bugs against it.

Comment 1

[Mike Hommey [:glandium]]

Let's say that having a MozillaBuild released with mozmake is the trigger that should allow us to remove it.

Comment 2

[Mike Hommey [:glandium]]

Attachment: Remove dumbmake

Comment 3

[Mike Hommey [:glandium]]

Attachment: Remove dumbmake

I think it's time to kill it.

Comment 4

[Gregory Szorc [:gps]]

I think frontend developers may still rely on it. I agree that the libxul parts aren't needed with the binaries target.

Can you send out an email to at least [e-mail] and give people the opportunity to object?

Comment 5

[(no longer active)]

Please ask about this on dev-platform as well.  This affects more than just the front-end developers.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Is it expected that "mach build binaries" doesn't rerun WebIDL codegen?

Comment 7

[Mike Hommey [:glandium]]

(In reply to Boris Zbarsky [:bz] from comment #6)
> Is it expected that "mach build binaries" doesn't rerun WebIDL codegen?

dumbmake doesn't either.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Hmm.  "mach build dom/bindings" does (reruns codegen, builds in bindings, relinks libxul).  Is that not using dumbmake?  It sounded from your post to firefox-dev that this is exactly the dumbmake case....

Comment 9

[(no longer active)]

(In reply to comment #7)
> (In reply to Boris Zbarsky [:bz] from comment #6)
> > Is it expected that "mach build binaries" doesn't rerun WebIDL codegen?
> 
> dumbmake doesn't either.

Doesn't dumbmake go through all of the tiers in thoise directory?  I'm 99.99% positive that it does based on my personal experience.

Comment 10

[Gregory Szorc [:gps]]

dumbmake is effectively a glorified expansion of |make -C foo| into |make -C foo && make -C bar && make -C baz|. So, yes, dumbmake should go through all the tiers. If /dom or /dom/bindings is in the expansion, WebIDL codegen should run (if needed) using the regular build system rules.

The "binaries" make target already processes install manifests. I can make a case for it also performing WebIDL, XPIDL, etc codegen as well.

At the end of the day, we can make custom build/make targets do whatever we want. I'm a huge fan of supporting top-level targets to satisfy common developer workflows until no-op and light builds take milliseconds and there is no need for these shortcuts. I'd prefer we do this rather than burden developers with knowledge of tiers, traversal rules, etc (especially since these things tend to change). Either we change "binaries" to do more work (at the cost of making it a little slower), or we add new target(s) that do binaries + other things.

Comment 11

[Gregory Szorc [:gps]]

Comment on attachment 8357463 [details] [diff] [review]
Remove dumbmake

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

I am reluctantly granting r+. I have concerns the discussion on removing dumbmake has centered around libxul workflow, where `make binaries` is a sufficient replacement for dumbmake. I worry about the impact on the workflow for browser developers, where dumbmake is relied upon more. I'd really like to see a "binaries" equivalent target that satisfies the needs of "frontend" developers. If we can do that before dumbmake is removed, I'll feel much better.

That being said, I am granting r+. We can always revert if there is backlash.

Comment 12

[Gregory Szorc [:gps]]

Cancelling a 2 year old needinfo.

Comment 14

[Ricky Stewart]

Attachment: Bug 925350 - Remove `dumbmake`

After bug 1651806, we're trying to caution people against running mach build $A_SPECIFIC_TARGET because it's not generally supported. dumbmake is a piece of infrastructure that attempts to make this use case a little bit more useable, but it was always supposed to be a stopgap. There doesn't seem to be a need for it any more.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f138bffc6fd1
Remove `dumbmake` r=nalexander

Comment 16

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/f138bffc6fd1