Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Intent to remove client.mk

19 views
Skip to first unread message

Gregory Szorc

unread,
Oct 27, 2017, 7:16:51 PM10/27/17
to dev-platform, dev-builds
client.mk has existed since 1998 (https://hg.mozilla.org/experimental/mozilla-central-cvs/rev/0a5e1fa423bd). Before `mach`, client.mk was the recommended way to build Firefox and perform other build tasks. client.mk has rarely changed in recent years because the build system maintainers have been working around it and because not much has changed around how the very early parts of "invoke the build system" work.

The build system maintainers are making a significant push towards supporting building Firefox without GNU make in this and future quarters.

Since client.mk is a make file and we want to not require make to build Firefox, client.mk is incompatible with our vision for the future of the Firefox build system. Furthermore, client.mk represents an ancient piece of build system infrastructure and its convoluted content creates consternation and inhibits forward progress. For these reasons, I'm announcing the intent to remove client.mk.

If you have tools, infrastructure, workflows, etc that use client.mk - or any direct use of `make` for that matter - please transition them to `mach` commands and/or check with a build peer regarding your use case. You can file bugs regarding client.mk dependencies against bug 1412398.

Thank you for your understanding.

Kris Maglione

unread,
Oct 27, 2017, 7:47:20 PM10/27/17
to Gregory Szorc, dev-builds, dev-platform
On Fri, Oct 27, 2017 at 04:16:01PM -0700, Gregory Szorc wrote:
>client.mk has existed since 1998 (
>https://hg.mozilla.org/experimental/mozilla-central-cvs/rev/0a5e1fa423bd).
>Before `mach`, client.mk was the recommended way to build Firefox and
>perform other build tasks. client.mk has rarely changed in recent years
>because the build system maintainers have been working around it and
>because not much has changed around how the very early parts of "invoke the
>build system" work.
>
>The build system maintainers are making a significant push towards
>supporting building Firefox without GNU make in this and future quarters.

I think I speak for all of us when I say: \o/

Nicholas Nethercote

unread,
Oct 27, 2017, 11:16:19 PM10/27/17
to Gregory Szorc, dev-builds, dev-platform
This is excellent news.

Relatedly, I want to particularly say that I think moz.build files are great. The syntax and semantics are very clear. They're easy to modify. They handle both simple cases and complex cases well. They pretty much never get in the way, which is exactly what a developer wants from a build system. The contrast with Makefiles is... significant.

Nick

On Sat, Oct 28, 2017 at 10:16 AM, Gregory Szorc <g...@mozilla.com> wrote:
client.mk has existed since 1998 (https://hg.mozilla.org/experimental/mozilla-central-cvs/rev/0a5e1fa423bd). Before `mach`, client.mk was the recommended way to build Firefox and perform other build tasks. client.mk has rarely changed in recent years because the build system maintainers have been working around it and because not much has changed around how the very early parts of "invoke the build system" work.

The build system maintainers are making a significant push towards supporting building Firefox without GNU make in this and future quarters.

Since client.mk is a make file and we want to not require make to build Firefox, client.mk is incompatible with our vision for the future of the Firefox build system. Furthermore, client.mk represents an ancient piece of build system infrastructure and its convoluted content creates consternation and inhibits forward progress. For these reasons, I'm announcing the intent to remove client.mk.

If you have tools, infrastructure, workflows, etc that use client.mk - or any direct use of `make` for that matter - please transition them to `mach` commands and/or check with a build peer regarding your use case. You can file bugs regarding client.mk dependencies against bug 1412398.

Thank you for your understanding.

_______________________________________________
dev-builds mailing list
dev-b...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds


Gregory Szorc

unread,
Nov 13, 2017, 6:17:03 PM11/13/17
to Gregory Szorc, dev-builds, dev-platform
On Fri, Oct 27, 2017 at 4:16 PM, Gregory Szorc <g...@mozilla.com> wrote:
client.mk has existed since 1998 (https://hg.mozilla.org/experimental/mozilla-central-cvs/rev/0a5e1fa423bd). Before `mach`, client.mk was the recommended way to build Firefox and perform other build tasks. client.mk has rarely changed in recent years because the build system maintainers have been working around it and because not much has changed around how the very early parts of "invoke the build system" work.

The build system maintainers are making a significant push towards supporting building Firefox without GNU make in this and future quarters.

Since client.mk is a make file and we want to not require make to build Firefox, client.mk is incompatible with our vision for the future of the Firefox build system. Furthermore, client.mk represents an ancient piece of build system infrastructure and its convoluted content creates consternation and inhibits forward progress. For these reasons, I'm announcing the intent to remove client.mk.

If you have tools, infrastructure, workflows, etc that use client.mk - or any direct use of `make` for that matter - please transition them to `mach` commands and/or check with a build peer regarding your use case. You can file bugs regarding client.mk dependencies against bug 1412398.

Thank you for your understanding.

Heads up: the patches to ween off client.mk have started landing. As I'm touching the code, it is obvious how brittle things are and that there is a web of under-documented dependencies everywhere I look.

If you see the build system behaving in strange ways - e.g. running configure twice, complaining about clobbers when it shouldn't, running moz.build sandbox evaluation when it shouldn't, etc, please don't hesitate to make noise in #build or file a bug blocking 1412398. Even if we break a workflow you relied on and there isn't a good equivalent, we'd like to know. Disrupting people unnecessarily is definitely not a goal of this refactor.
0 new messages