Better incremental builds - Tup backend available on Linux
Hi everyone, Tup is a modern build system that enables fast and correct builds. I'm pleased to announce the availability of Tup for building Firefox on Linux. Compared to Make, building with Tup will result in faster incremental build times and reduce the need for clobber builds. See the in-tree docs for details [1]. We announced this on dev-builds[2] a few weeks ago, and addressed much of the feedback from early adopters. Now we’re looking for more users to try it out and let us know what issues you have, and whether or not it improves your development workflow. Quick howto: You’ll need to install the Tup executable, as well as the nightly rust/cargo toolchain: cd ~/.mozbuild && mach artifact toolchain --from-build linux64-tup rustup default nightly-2018-09-16 * Note that normally “rustup default nightly” would suffice, but until https://github.com/rust-lang/cargo/issues/6082 is in nightly, try 2018-09-16 for now. Your mozconfig needs to describe how to find the executable if it’s not in your PATH, and enable the Tup backend: export TUP=~/.mozbuild/tup/tup ac_add_options --enable-build-backends=Tup If you have any issues, feel free to file a bug blocking “buildtup” [3], or contact mshal or chmanchester in #build on IRC. [1] https://firefox-source-docs.mozilla.org/build/buildsystem/tup.html [2] https://groups.google.com/d/msg/mozilla.dev.builds/c4rxss-ScmM/8M8fo_uzDAAJ [3] https://bugzilla.mozilla.org/show_bug.cgi?id=buildtup Thanks! -Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
tamarin-redux
After finding a new version of nanojit on github https://github.com/dibyendumajumdar/nanojit and updating zlib I was able to get tamarin-redux to compile but not link does anyone else want to work on actionmonkey.? Thank You, Jonathan Moore ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Windows launcher process enabled by default on Nightly
On 9/28/2018 12:10 PM, Ehsan Akhgari wrote: Is the --wait-for-browser flag the default in headless mode, since that mode is mostly for automation Good question. We already do that for --marionette, but not for headless. I have filed bug 1495049 to add this. Aaron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Windows launcher process enabled by default on Nightly
On 9/27/2018 1:53 PM, David Teller wrote: It sounds cool, but I'm trying to understand what it means :) Do I understand correctly that the main benefit is security? In its current form, there are currently two primary security benefits that the launcher process provides: * When the launcher process detects that it has been started with administrator privileges, it creates the browser process with a non-administrative integrity level. * When run on Windows 10 Anniversary Update or newer, we activate a kernel mitigation that alters the dynamic linker's search path such that it always attempts to load DLLs from the Windows system32 directory first, before attempting other directories. Stability benefits: As for the stability benefits, we cannot realize most of them yet. Once we have validated the performance and functionality of the launcher process and the basic implementation reaches release, we will be able to do much more interesting things on the stability front. Feel free to reach out to me off-list if you'd like to make further inquiries about our future plans for this. Aaron ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Windows launcher process enabled by default on Nightly
On Thu, Sep 27, 2018 at 11:19 AM Aaron Klotz wrote: > 1. Automation > - > > If you are doing some kind of automation that waits for the Firefox > process to finish, you'll find that the initial Firefox process exits > sooner than the browser, appearing to your script that Firefox is > already done when in fact it is still running. This is because, by > default, the launcher process only lives long enough to stand up the > browser process and transfer foreground to the new browser's window. > > In order to make the launcher wait for the browser to complete, pass the > --wait-for-browser flag on the command line. The launcher will wait for > the entire life of the browser process, and will also propagate the > browser process's exit code as its own. The launcher also accepts the > presence of the MOZ_AUTOMATION environment variable as an implicit > --wait-for-browser request. > > I have already fixed up our automation to supply this parameter when > necessary, so I expect everything in Mozilla's CI system to already Just > Work. > Is the --wait-for-browser flag the default in headless mode, since that mode is mostly for automation Thanks, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Windows launcher process enabled by default on Nightly
On 9/27/2018 9:47 AM, Ted Mielczarek wrote: We have `MOZ_DEBUG_CHILD_PROCESS` for e10s content processes[1]. Would something similar (or maybe just supporting that?) be useful for the browser process as well? Sure, I have filed bug 1495039. * If you use WinDbg, you may start your debugging session from the command line with the "-o" option to ensure that the debugger attaches to all child processes. If you prefer opening your executable via the GUI, you may select the "Debug child processes also" checkbox within the "Open Executable" file picker. * If you use Visual Studio, you may install the Child Process Debugging Power Tool [3] which, once configured, will make the VS debugger automagically attach to the launcher's child processes. Can we make these work automatically via mozdebug so that `mach run --debug` works directly? Sure. I have filed bug 1495040. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
