We should stop supporting GNU make on Windows and require Pymake. Since mach uses Pymake automatically, the error message could instruct the user to use "./mach build" instead.

Just a note that when a bit mysterious bug 824004 that disappears and reappears at its own will is not resolved I may be completely blocked from build the tree. It means that all pymake related issues must be resolved or a override for this requirement must be available. Personally I don't understand why you want to remove the GNU make supports at all.

(In reply to Honza Bambas (:mayhemer) from comment #1) > Personally I don't understand why you want to remove the GNU make supports > at all. It is easier to support and debug N - 1 build configurations.

OK, if that is just about "not supporting" in means of not maintaining the code by some paid mozilla contributor, then I think we could just claim the support is dead but leave the option be supported by the community (here me). If that is possible of course and doesn't mean to still leave effort on build config developers. I'm just worried to get blocked from work by being dependent on faulty pymake with no other option to build.

Our tinderbox machines are building with pymake, so GNU make is no longer a well-tested solution. Furthermore, GNU make on Windows has a long-standing bug where it hangs with multi-core builds, meaning that it's a huge potential footgun. Finally, because of path differences between pymake and gmake, supporting both means that it's hard (or impossible) to get a bunch of corner cases right (for example, bug 773423).

I would like this configuration to error out so that users don't accidentally use an unsupported tool and find themselves with strange errors as a result.

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #4) > Our tinderbox machines are building with pymake, so GNU make is no longer a > well-tested solution. Furthermore, GNU make on Windows has a long-standing > bug where it hangs with multi-core builds, meaning that it's a huge > potential footgun. Yeah, I know this very well ;) > Finally, because of path differences between pymake and > gmake, supporting both means that it's hard (or impossible) to get a bunch > of corner cases right (for example, bug 773423). This is an argument then. Ted, I hope I can count on you to help with any issues that would prevent build the tree only with pymake where make might work.

Absolutely. Pymake is our officially supported build platform for Windows, so bugs there are always important.

This bug could use a patch! I don't have access to a Windows machine ATM, so this patch is untested. Would appreciate testing as part of review. Or, I can wait until Wednesday to test on Windows myself and/or use Try.

Comment on attachment 715276 [details] [diff] [review] Require pymake to build on Windows, v1 Why not just run pymake instead of complaining?

(In reply to Mike Hommey [:glandium] from comment #9) > Comment on attachment 715276 [details] [diff] [review] > Require pymake to build on Windows, v1 > > Why not just run pymake instead of complaining? for clarification: "why not just have make run pymake instead of erroring-out?" is what was meant above.

Is there a robust way to obtain all the arguments passed into make? Yes, you can use $(MAKEFLAGS). But how do you get at -C and/or -f? $(firstword $(MAKEFILE_LIST))? My personal opinion here is people should start using an intelligent driver (like mach) that automatically selects the appropriate build backend for them (which may not be make/pymake in the future).

(In reply to Gregory Szorc from comment #11) > Is there a robust way to obtain all the arguments passed into make? Yes, you > can use $(MAKEFLAGS). But how do you get at -C and/or -f? $(firstword > $(MAKEFILE_LIST))? FYI, -C doesn't apply because gmake will already have changed to the appropriate directory. The only time I use -f is for client.mk which I don't think includes rules.mk anyway. (This makes it easy to search shell history for -f to find the command to rebuild the whole tree!)

(In reply to Mike Hommey [:glandium] from comment #10) > > Why not just run pymake instead of complaining? > > for clarification: "why not just have make run pymake instead of > erroring-out?" is what was meant above. It's great. I'm tired to type "./build/pymake/make.py". (In reply to Gregory Szorc [:gps] from comment #11) > My personal opinion here is people should start using an intelligent driver > (like mach) that automatically selects the appropriate build backend for > them (which may not be make/pymake in the future). I'm usually using ./mach, but I still have to use make at the moment. For example, bug 842387. Another example is building only the part of the tree. If I have to rebuild the entire tree whenever I changed something, it would be virtually impossible to develop Firefox on my slow laptop.

(In reply to Masatoshi Kimura [:emk] from comment #13) > I'm usually using ./mach, but I still have to use make at the moment. For > example, bug 842387. Another example is building only the part of the tree. > If I have to rebuild the entire tree whenever I changed something, it would > be virtually impossible to develop Firefox on my slow laptop. $ ./mach build toolkit browser That will perform an incremental build.

(In reply to Gregory Szorc [:gps] from comment #14) > (In reply to Masatoshi Kimura [:emk] from comment #13) > > I'm usually using ./mach, but I still have to use make at the moment. For > > example, bug 842387. Another example is building only the part of the tree. > > If I have to rebuild the entire tree whenever I changed something, it would > > be virtually impossible to develop Firefox on my slow laptop. > > $ ./mach build toolkit browser > > That will perform an incremental build. I just checked it works also for submodules like src$ mach build netwerk/protocol/http/ But I hope that doing... src/_obj$ pymake -C network/protocol/http ... is going to be preserved as well?

(In reply to Honza Bambas (:mayhemer) from comment #15) > But I hope that doing... > > src/_obj$ pymake -C network/protocol/http > > ... is going to be preserved as well? We have no short-term plans to stop supporting that. Longer-term we hope to get rid of Makefiles as the build backend, so think of "mach build" as the carrot to change your habits so you don't get broken eventually. :)

Comment on attachment 715276 [details] [diff] [review] Require pymake to build on Windows, v1 Review of attachment 715276 [details] [diff] [review]: ----------------------------------------------------------------- Can you put the same check in client.mk so we can error out early there as well?

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #16) > We have no short-term plans to stop supporting that. Longer-term we hope to > get rid of Makefiles as the build backend, so think of "mach build" as the > carrot to change your habits so you don't get broken eventually. :) I'm asking because I sometimes have more then just one _obj dir under my source dir, with different configs (browser, b2g X debug, optimized, tests etc..) and I work with both build configs using the same sources. Then I just cd to the _obj I want to build, do my build commands for modules. And when I want to rebuild the same modules in other build config, I just cd ../_obj2 and use bash history to quickly repeat build commands. If mach build can also support switch between .mozconfigs (actually having an option to specify a custom .mozconfig would be great!) then I'm OK.

(In reply to Gregory Szorc [:gps] from comment #14) > (In reply to Masatoshi Kimura [:emk] from comment #13) > > I'm usually using ./mach, but I still have to use make at the moment. For > > example, bug 842387. Another example is building only the part of the tree. > > If I have to rebuild the entire tree whenever I changed something, it would > > be virtually impossible to develop Firefox on my slow laptop. > > $ ./mach build toolkit browser > > That will perform an incremental build. Oh, when I tried it before, it didn't work. Is there an corresponding mach command to "./build/pymake/make.py -C path/to/objdir/ export"? I'm often using it to reduce the turn-around time.

Justin: I think you mentioned on IRC that SeaMonkey and possibly comm-central doesn't build with pymake yet. I don't want to push this out before you are ready. But, I don't want to wait indefinitely either. What timetable is good for you?

(In reply to Honza Bambas (:mayhemer) from comment #18) > If mach build can also support switch between .mozconfigs (actually having > an option to specify a custom .mozconfig would be great!) then I'm OK. mach supports the MOZCONFIG environment variable to define which mozconfig is in effect: MOZCONFIG=foo ./mach build MOZCONFIG=bar ./mach build (In reply to Masatoshi Kimura [:emk] from comment #19) > Oh, when I tried it before, it didn't work. > Is there an corresponding mach command to "./build/pymake/make.py -C > path/to/objdir/ export"? > I'm often using it to reduce the turn-around time. This is bug 837824.

(In reply to Gregory Szorc [:gps] from comment #20) > Justin: I think you mentioned on IRC that SeaMonkey and possibly > comm-central doesn't build with pymake yet. I don't want to push this out > before you are ready. But, I don't want to wait indefinitely either. What > timetable is good for you? SeaMonkey is indeed not ready for pymake yet, we're working on it. But we're also broken due to Bug 842341 right now, so long as we don't have pymake. :ted doesn't seem willing to fix that though (see c#3) So my priority is "fix that" so we can get SeaMonkey trunk and aurora building again. If it is deemed wontfix we can land this, since we're broken anyway. Either way, we're actively working on pymake in Bug 842445, and expect within the next few weeks to be switched over on trunk.

Now with client.mk integration.

Waiting on SeaMonkey (until we get impatient).

It's been a month. Is SeaMonkey ready?

(In reply to Gregory Szorc [:gps] from comment #25) > It's been a month. Is SeaMonkey ready? We discussed in IRC recently that its not *only* waiting on SeaMonkey now, it was waiting on l10n bustage. We switched over a while ago for our main builds but l10n (also for Firefox) was broken when we required pymake. As discussed in IRC then enabling pymake my default is ok if you exclude l10n (e.g. --with-l10n-basedir and --disable-compile-environment as seperate switches to allow without pymake)

Ted is sitting next to me and we both agreed there is no time like the present. https://hg.mozilla.org/integration/mozilla-inbound/rev/c750d5d003dd