Re: Builds docs on MDN

[Nicholas Nethercote]

There are multiple kinds of docs. One group that I've done a lot of work on
is the collection of pages under
https://developer.mozilla.org/en-US/docs/Mozilla/Performance. I'm not sure
if in-tree would be better for those or not, but they're certainly in a
different category to API docs, for example.

Nick

On Wed, Jun 21, 2017 at 12:50 PM, ISHIKAWA,chiaki 
wrote:

> On 2017/06/21 2:19, Ehsan Akhgari wrote:
>
>> On 06/20/2017 12:55 PM, Benjamin Smedberg wrote:
>>
>>>
>>>
>>> On Tue, Jun 20, 2017 at 12:40 PM, Ehsan Akhgari >> > wrote:
>>>
>>> On 06/20/2017 11:21 AM, Benjamin Smedberg wrote:
>>>
>>> Coming in late to this thread, but I'd like to strongly
>>> support moving our Mozilla internals documentation in the tree.
>>>
>>> It seems that the rest of your post is mostly advocating that we
>>> should write documentation, which is hard to argue with.  For the
>>> record it's not clear to me how you connect that to it being a
>>> better choice for the said documentation to live in the tree.
>>> (Since you mentioned the anecdotal successful example of telemetry
>>> ping documentation, let me counter it with the anecdotal
>>> successful example of WebIDL bindings documentation which lives
>>> out of the tree:
>>> https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings
>>> .)
>>>
>>>
>>> I'll put nuance on this. I do think we should be writing docs, but I
>>> think it's much more important that we're maintaining and deleting existing
>>> docs as the code changes or becomes irrelevant.
>>>
>> Something that a wiki is much more suitable for.  ;-)
>>
>>> That's why I think the choice of in-tree versus external tool is
>>> important and not merely a tooling choice. Documentation that is in the
>>> tree can/should  be reviewed as the code changes. Partly because it is in
>>> the tree, it maps to Mozilla module ownership and module owners can
>>> exercise ownership over their slice of documentation explicitly.
>>>
>> This is the part that I don't understand.  You are implying that by not
>> having some text file containing the documentation inside the tree we can't
>> enforce review over documentation, and that they can't be updated alongside
>> code changes.  I chose the example of WebIDL bindings documentation very
>> consciously to demonstrate that these are false assertions.  That example
>> clearly demonstrates that reviewers can (and certainly do) ask patch
>> authors to fix the documentation when they make code changes, such
>> documentation fixes are reviewed by the right people and the resulting docs
>> stay in good shape.
>>
>>
> I am a volunteer who occasionally submit patches to C-C TB.
>
> In-tree documentation is much easier for volunteers to work with.
> The documentation is much closer to the code we are modifying.
>
> Out of tree docs are much harder to deal with.
> Just adding a few (actually more)  keystrokes to access them make it
> rather difficult, or more to the point TIME-CONSUMING to work with.
>
> For unpaid volunteers (and I assume even for paid developers), in-tree
> documentation is much easier to work with in terms of overhead of JUST
> checking WHERE on earth the relevant documentation exists (IF IT EXISTS AT
> ALL) and then out-of-tree documentation in an other system means we still
> need work with DIFFERENT set of rules that exist for accountability for
> modification.
>
> Given these overhead,  out-of-tree documentations are basically something
> volunteer patch submitters won't be able to work with: I suspect "Just
> forget it" would be what many volunteer submitters would feel after a while.
>
> Initially, when people start to submit patches, they may think what they
> might need to do with the documentation aside from DOCS style annotations
> inside the code itself.
> But then  the current anarchy of documents scattered around makes you
> realize finding relevant documentation is hard. You never know if you have
> found all relevant documentation there is to the particular module, etc.
> after google search, say.
>
> That's when "Forget it" makes sense :-(
>
> Of course, if someone points out relevant docs in an exact manner showing
> URLs and such, that is another story.
> But I wonder, though, whether OTHER contributors could find THOSE
> DOCUMENTS on their own in the future. I bet they don't most of the times.
>
> The result is the almost document-less (in practical terms)
> hard-to-modify C-C source tree IMHO.
>
> I suspect M-C is not that different in terms of document-friendliness
> given some arcane bugs that were not fixed for many years.
>
> The reliance of web tools for documentation is a little overblown.
> Relevant documents should live near the source code.
> Just creating a DOC directory for each module will go a long way
> - to consolidate the docs in 

Re: Intent to remove client.mk

[Nicholas Nethercote]

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  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-builds@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-builds
>
>
___
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds

Re: Better incremental builds - Tup backend ready for early adopters on Linux

[Nicholas Nethercote]

 >  * You must be using an in-tree OBJDIR.

Does it handle multiple in-tree objdirs? E.g. I have d64 (debug), o64
(opt), etc.

Nick


On Tue, Aug 7, 2018 at 11:18 PM, Jonathan Watt  wrote:

> This is great! A big thank you to all the folks who have worked for so
> long to
> get us to this stage. I'm really looking forward to this work maturing and
> extending to other platforms.
>
> I've done a bit of testing on my workstation (14 core/28 thread i9, U.2
> connected NVMe SSD, 64 GB DDR4 RAM) and got the following build times:
>
> For -j28 (yes, -j28 is well into diminishing returns territory, but I
> wanted a
> comparison of the best case scenarios for both backends):
>
>   |  cold   |top-level
>   |  initial build  |  no-op rebuild
> --
> make  |  8m 10s |   15s
> tup   |  6m 35s |1.4s
>
> And for -j8:
>
>   |  cold   |top-level
>   |  initial build  |  no-op rebuild
> --
> make  | 11m 33s |   15s
> tup   | 10m 52s |1.4s
>
> (To confirm: the rebuild numbers are the same for both -j28 and -j8.)
>
> So a 20% reduction in build time on cold builds of a fresh tree with -j28,
> and
> 6% reduction with -j8. In addition to speeding up the build, Tup seems to
> parallelize better which is great! Of course the highlight is the big
> reduction
> in rebuild overhead which will make the edit-compile-run cycle a lot less
> annoying (for me, 50s down to 37s after touching nsDocumentViewer.cpp,
> rebuilding, and linking libxul, for both -j28 and -j8.)
>
> These improvements, plus the promise of rarely having to clobber/figure out
> which directories to rebuild in, put a big smile on my face. (Currently
> having
> to turn off CARGO_INCREMENTAL, not being able to use sccache and other
> current
> limitations, less so, but it's early days. :) )
>
> A few notes for others trying this out (thanks cmanchester and mshal for
> the
> help debugging some of these):
>
>   * Make sure you use:
>
>   --enable-build-backends=Tup
>
> not:
>
>   --enable-build-backend=Tup
>
>   * You must be using an in-tree OBJDIR.
>
>   * MOZ_PARALLEL_BUILD isn't currently recognized, so you'll need to use
> `mach build`s -j argument to control the parallel job count for now
> ( see https://bugzilla.mozilla.org/show_bug.cgi?id=1481441 )
>
> mshal: I think you could cross-post this to dev-platform for wider
> testing. I
> know there are a bunch of caveats (which people should be made aware of),
> but
> since the initial teething issues I had were figured out I've so far had no
> other problems building, or rebuilding with real code changes.
>
> Jonathan
>
> On 02/08/2018 16:34, Michael Shal wrote:
> > 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’re looking for some early adopters to try it out and let us know if it
> > improves your workflow, or if you hit any blockers or barriers to
> adoption that
> > keep you on the Make backend for now.
> >
> >
> > 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 install nightly
> > rustup default nightly
> >
> > 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” [2],
> or
> > contact mshal or chmanchester in #build on IRC.
> >
> > [1] https://firefox-source-docs.mozilla.org/build/buildsystem/tup.html
> >
> > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=buildtup
> >
> >
> > Thanks!
> >
> > -Mike
> >
> >
>
> ___
> dev-builds mailing list
> dev-builds@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-builds
>
___
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds