When I modified ehsan's patch in bug 904572 to switch to a build backend
instead of a mach command, I forgot to remove the line added to
mach_bootstrap.py to pick the mach command, which now doesn't exist.
Pymake's clinetoargv is very specific to pymake's use case, yet has been abused
as a replacement for shlex because shlex doesn't handle things properly for our
use cases.
Using pymake's clinetoargv, however, has shortcomings, and we're better off
importing its code in mozbuild, simplifying it a little, and using that
instead.
Plus, less dependencies on pymake will help kill it for good some day.
This extracts the most useful browser-related measurements from rapl and
powermetrics.
--HG--
extra : rebase_source : 81ce14acc6c6e1bc7ac6c34bf119d8e619956dd1
This included adding the slugid 1.0.6 python source code in /python since slugid
is now a dependency of the ./mach taskcluster-graph command, as well us updating
references that used it. Previously the implementation was in-tree.
This also completely remove build/automationutils.py.
--HG--
extra : commitid : 50v6EAQNEHV
extra : rebase_source : 4ac1347d73498f068979514c6afb16ac50ab4033
It's been clear from user feedback that people don't realize that `mach
mercurial-setup` doesn't make any changes unless they tell it to.
Reinforce this message in the prompts printed by mach_boostrap.py.
--HG--
extra : commitid : DmE2U8DHQ3M
extra : rebase_source : 20e5c4d6ff7610bdceef7817c5ea2854d271ccdf
isatty() raises ValueError if the file descriptor is closed. Detect
closed file descriptors.
--HG--
extra : commitid : 3wH6lYWoPHZ
extra : rebase_source : df0f657a3b2afa6dbc710e98c0b3c31f3b8be486
extra : amend_source : 7a153ea95c7b77cf0d53116d70c7a840fbbdb92e
This command is used by tab completion handlers. A user reported that
hitting tab in his shell resulted in the mercurial-setup out of date
check spewing output.
--HG--
extra : commitid : 5DE199lHcn2
extra : rebase_source : 7f2ef1c325b3f0deb091798a5d21820257d6c1f6
extra : amend_source : 016428cf3d2442cc2ced24d328aec53a752619ab
Having not configured or out-of-date tools benefits nobody. It slows
people down.
Version control tools are an integral part of working on Firefox. It is
important for version control tools to be configured optimally and to be
continuously updated so they stay optimal.
The `mach mercurial-setup` command exists to optimally configure
Mercurial for working on Firefox and other Mozilla projects.
This commit adds a pre-dispatch handler to mach that will verify
Mercurial is in a happy state. If `mach mercurial-setup` has never
executed, it will complain. If `mach mercurial-setup` hasn't been
executed in the past 31 days, it will complain.
Yes, aborting command execution and forcing people to context switch to
run `mach mercurial-setup` is annoying. First, we have carved out
several exceptions to this behavior, including detection for running in
automation, on the machines of curmudgeons, when Mercurial isn't being
used, and from non-interactive processes. Second, I argue that people
ignore optional notifications and that having persistently
poorly-configured tools is worse than a single context switch at most
every month. Therefore, the heavyhanded approach is justified.
In addition, if we did support a non-fatal notification, we would
introduce the problem of extra output from commands. If anyone was e.g.
parsing mach output, we could very likely break those systems. These
cases should be caught by the isatty() check or be running in a context
with MOZ_AUTOMATION set. But you never know.
--HG--
extra : commitid : 7f7JQpa953u
extra : rebase_source : 47b6304b6ac2c9d8136f2023a7d03df7d1f45e4f
extra : source : f06616ee7b2b54d63d20ee4795539514d1df8c7b
Having not configured or out-of-date tools benefits nobody. It slows
people down.
Version control tools are an integral part of working on Firefox. It is
important for version control tools to be configured optimally and to be
continuously updated so they stay optimal.
The `mach mercurial-setup` command exists to optimally configure
Mercurial for working on Firefox and other Mozilla projects.
This commit adds a pre-dispatch handler to mach that will verify
Mercurial is in a happy state. If `mach mercurial-setup` has never
executed, it will complain. If `mach mercurial-setup` hasn't been
executed in the past 2 weeks, it will complain.
Yes, aborting command execution and forcing people to context switch to
run `mach mercurial-setup` is annoying. First, we have carved out
several exceptions to this behavior, including detection for running in
automation, on the machines of curmudgeons, when Mercurial isn't being
used, and from non-interactive processes. Second, I argue that people
ignore optional notifications and that having persistently
poorly-configured tools is worse than a single context switch at most
every 2 weeks. Therefore, the heavyhanded approach is justified.
In addition, if we did support a non-fatal notification, we would
introduce the problem of extra output from commands. If anyone was e.g.
parsing mach output, we could very likely break those systems. These
cases should be caught by the isatty() check or be running in a context
with MOZ_AUTOMATION set. But you never know.
--HG--
extra : commitid : AWLag0bpQOY
extra : rebase_source : fba19b918e9eadc6d5976c10d82974fb7e835e9d
A subsequent commit will want to access the state directory path without
possibly creating it. Make that possible by extracting path resolution
to its own function.
--HG--
extra : commitid : 60aMbblXNF9
extra : rebase_source : 5e83e36d32ff1f581e91b442005139c89f3bc3f3
We're using as many defaults from the configure step as we can. We're also opinionated upon the defaults, but obviously allow most compare-locales options to be specified.
There are two exceptions:
Reference language is specified to be en-US, without optional argument. This is our in-tree command, and the reference language is known.
We always clobber the merge dir, and don't give an option not to. We default to a merge dir in the objdir, so we don't need to be that paranoid as in the standalone version.
Also, compare-locales clobbers merge-dir/browser etc, so you're not going to get / removed.
--HG--
extra : rebase_source : c0f63e566779e83201708d05966f3583ae82e4ee
I went with gradle instead of gradlew because it's more likely to be
what users consider. And mach helpfully fixes up the uncommon typo.
This is a little hard-coded right now but I don't think it's likely
any other Gradle consumer will arise in the short term.
--HG--
extra : source : 67ce3d7591f944fa458758d97f443651f0e40dac
extra : amend_source : d10846e845deda5d368bdfdbb5b3d68706038992
extra : histedit_source : fb30750f389444a9619778d4c690d7de5e5fcbc1
The immediate goal of this patch is to give the build system and testing
tools the knowledge to identify reftest files and directories. Parsing
extra metadata out of reftest manifests is currently a non-requirement,
but may be supported some day.
--HG--
extra : rebase_source : 279680af28c9175f5babe458a57203e8b19ab724
extra : histedit_source : c0e463ea02f87a376ef48e2b25136e5f6be4e61a
