Previously on first `mach` run on a system, we'd display a prompt with a
20s countdown timer after which the default state directory
(~/.mozbuild) was created. Users had to wait 20s or ctrl+c and
make the directory by hand. Either way, they'd have to re-invoke
mach to run whatever command they were trying to run.
This was annoying.
This commit makes the following changes:
1) The countdown timer is replaced with "press RETURN/ENTER to continue"
2) The requirement to re-invoke mach has been removed
On first run, people now see a message telling them to press
RETURN/ENTER. Then the directory is created and whatever mach command
they requested to run is run.
While I was here, I also changed the permissions on the newly created
directory to match what it was a few lines above. Without, we're relying
on umask, which may be permissive. UNIX convention is to use a more
restrictive umask insider user directories. So this feels like the right
behavior.
MozReview-Commit-ID: IodN13xAJ8P
--HG--
extra : rebase_source : 7da66e2f03aaf4e6807c54ac20854a4f41092f2a
We should use GetAsciiSpec for idn and non-ASCII path
MozReview-Commit-ID: EjldSMJYUDg
--HG--
extra : rebase_source : 87b9680d4ed6268b0779d8603e824625c7b6f98c
* this also fixes bug where we take build/0 from tc artifacts regardless if
there was a retry
MozReview-Commit-ID: KKJCGF6Hc7k
--HG--
extra : source : 23f241eec2af1ce07728a69ef53351371a43a85b
We don't process IPDL and WebIDL files during artifact builds. The
backend shouldn't need to care about them.
Before: 2001 total backend files; 2001 created; 0 updated; 0 unchanged; 0 deleted
After: 1945 total backend files; 1945 created; 0 updated; 0 unchanged; 0 deleted
After this change, we no longer write any .cpp files to the objdir
during config.status for artifact builds.
As part of this, we stopped generated webidlsrcs.mk and the build broke
because of an unguarded use in a Makefile.
After this change, only 102/3366 files in the objdir after
`mach configure` are not a) in _virtualenv b) named backend.mk
c) named Makefile (~950 each of backend.mk and Makefile).
MozReview-Commit-ID: 11AIn1i4x4f
--HG--
extra : rebase_source : ac90bb9f6be8b7b986aa0a61b3ccc203a18346a6
I can't think of a good reason why unified C++ files need to exist
during artifact builds. Let's not write them in this build config.
Before: 2517 total backend files; 2517 created; 0 updated; 0 unchanged; 0 deleted
After: 2001 total backend files; 2001 created; 0 updated; 0 unchanged; 0 deleted
No measureable change in performance on Linux. But on Windows where file
creation is in the ~1ms range, this will surely result in a speedup of
several hundred milliseconds.
We are still generating some .cpp files during artifact builds. This will be
addressed in subsequent commits.
MozReview-Commit-ID: Lqx36YE8qZZ
--HG--
extra : rebase_source : 8af5a9915e78af7aee2aa335552689fe33975400
Future commits will add a number of consumers. This will cut down on
boilerplate.
MozReview-Commit-ID: 8h4VWBXXd8O
--HG--
extra : rebase_source : 3376f015f1766eedcef60e9393b6d68474ffb634
The WindowsAddressSpaceReporter generates one memory report per segment, and
there can be 10,000+ segments.
This patch changes things so that one memory report is generated per segment
*kind* -- at most a couple of dozen -- rather than one per *segment*.
--HG--
extra : rebase_source : bbe86562ee486fd5fbb5d48ff2cc59a6f4c7b4c9
As previous measurements have shown, creating/appending files
on Windows/NTFS is slow because the CloseHandle() Win32 API takes
1-3ms to complete. This is apparently due to a fundamental issue
with NTFS extents. A way to work around this slowness is to use
multiple threads for I/O so file closing doesn't block execution
as much.
This commit updates the file copier to use a thread pool of 4
threads when processing file copies. Additional threads appear
to have diminishing returns.
On my i7-6700K, this reduces the time for processing the tests install
manifest (24,572 files) on Windows from ~22.0s to ~12.5s in the best
case.
Using the thread pool globally resulted in a performance regression
on Linux. Given the performance sensitivity of manifest copying,
I thought it best to implement a slightly redundant non-Windows
branch to preserve performance. For the record, that same machine
running Linux is capable of processing nearly the same install
manifest (24,616 files) in ~2.2s in the best case.
MozReview-Commit-ID: B9LbKaOoO1u
--HG--
extra : rebase_source : e9fee3861a70e1da9d18448f8435f4bd3e28c647
Cameron McCormack
Gregory Szorc
Phil Ringnalda
Bas Schouten
Steve Fink
Shu-yu Guo
Makoto Kato
Xidorn Quan
Blake Kaplan
Andrew McCreight
Alexander Surkov
Dave Townsend
Andrea Marchesini
Chris Pearce
Jordan Lund
Nicholas Nethercote
Benjamin Bouvier
aleth
Wes Kocher
Eugen Sawin
Boris Zbarsky
Kyle Huey
Armen Zambrano Gasparnian
Bogdan Postelnicu
Jonathan Watt