Re: Simple Thunderbird build says it's wrong, what's right?

On 6/13/19 7:15 PM, Paul Schauble wrote: Looking at the page "Simple Thunderbird build" under "Get the source", I see this note Warning: The page Getting comm-central Source Code Using Mercurial [en-US] is 99% out of date! Only useful content is working with Github. I'm not sure how to interp

Re: no matching function error in /mozilla-central/comm/mailnews/addrbook/src/nsAbLDAPListenerBase.cpp

On 6/13/19 6:56 AM, Aashlay Singla wrote: please help me out Make sure your source checkout includes the changes from . Chances are you just need to "hg pull -u" to pick those up. -Boris ___

Re: Avoiding the hard build dependency on NodeJS

On 11/7/18 9:30 AM, Martin Husemann wrote: Or port node to Spidermonkey, might be easier :-) True. https://github.com/mozilla/spidernode/ is not really active, but might be revivable... -Boris ___ dev-builds mailing list dev-builds@lists.mozilla.o

Re: Avoiding the hard build dependency on NodeJS

On 11/7/18 8:32 AM, Martin Husemann wrote: NodeJS seems to have no support at all for sparc CPUs, and I am not yet sure how hard it would be to add. You'd need to port V8 to work on sparc, right? That sounds fairly painful... -Boris ___ dev-build

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

On 8/8/18 3:48 PM, Michael Shal wrote: Yes, so it should work if you run 'tup init' manually in dir1 and again in dir2. I ran some tests on my machine, and it looks like each additional objdir only added about 100ms to the scan time. That's awesome. ;) -Boris

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

On 8/8/18 10:29 AM, Michael Shal wrote:  Yes, that should work, though with a caveat - you'd probably want to make sure that the common parent is only used for one srcdir and objdir. I definitely have multiple objdirs per srcdir. ;) opt and debug at the very least; in some cases a few othe

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

On 8/7/18 11:49 AM, Tom Prince wrote: Depending on what tool you use, it should be possible to exclude objdir's from search anyway. There are multiple tools, depending on what I'm doing. "find", "grep", "mkid" (from idutils) are the most common ones. "find" and "mkid" do have ways to exclud

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

On 8/7/18 11:27 AM, Jonathan Watt wrote: When I previously discussed that with mshal he said the following (edited to replace locations specific to my setup): "A little background about tup: by default it keeps track of everything in the directory where 'tup init' gets run, and all subdirectorie

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

On 8/7/18 9:18 AM, Jonathan Watt wrote: * You must be using an in-tree OBJDIR. Do you happen to know whether this is a temporary limitation or a permanent one? -Boris ___ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla

Re: Intent to require Node to build Firefox 61 and later

On 3/6/18 5:36 PM, Nicholas Alexander wrote: We (folks behind the Node proposal) are actively working with the folks behind this sibling proposal to ensure that we have a workable solution to upgrading Node dependencies across the tree in a timely manner in the face of security updates. Note

Re: Builds docs on MDN

On 6/16/17 9:33 AM, Ehsan Akhgari wrote: I certainly feel like the barrier for filing bugs, creating a patch, figuring out how to use readthedocs infrastructure, getting reviews, etc. isn't really worth it I believe we should not require filing bugs, reviews, or any of that for in-tree docs.

Re: Tests that aren't compiled in netwerk/test

On 1/5/17 9:51 AM, Ted Mielczarek wrote: If they're not even listed in moz.build then they're not doing anything but wasting people's time showing up in code search results. We should definitely remove them! Or start running them. It looks to me like this test was meant to be run (added in h

Re: Building Firefox on a 128 core machine

On 8/5/16 1:33 PM, Gregory Szorc wrote: The overhead of serialization/deserialization + process startup has a strong chance of canceling out any perf wins with Python. That's my gut feeling too, based on past measurements in this code. Despite the GIL, Python can get nice performance wins whe

Re: Building Firefox on a 128 core machine

On 8/5/16 12:20 AM, Gregory Szorc wrote: If someone could make WebIDL or IPDL processing faster, that would help people with high core machines, including distributed compilation environments. I believe WebIDL is the longer pole. Just to double-check that we're talking about the same numbers,

Re: Building Firefox on a 128 core machine

On 8/4/16 4:01 PM, Gregory Szorc wrote: * between the "export" and "compile" tiers (WebIDL and IPDL processing delay start of compile tier) Do we do WebIDL and IPDL stuff in parallel with each other? -Boris ___ dev-builds mailing list dev-builds@list

Re: Feature flags used in Firefox Source Code

On 7/26/16 9:09 AM, Akond Rahman wrote: I am looking into the usage of feature flags of open source software projects and I was wondering where I can find a list of all the feature flags used in Firefox source code. There is no canonical list, because code can just check a preference value a

Re: Interpreting treeherder results

On 7/12/16 1:55 AM, Mike Hommey wrote: If you have B and C depending on A that was not authored by you, it's probably already in your local branch, isn't it? That's one possible scenario, yes. But the version of A that actually lands may not match the one in my local branch (reviews, etc), so

Re: Interpreting treeherder results

On 7/12/16 1:29 AM, Gregory Szorc wrote: Your question implies to me that you are coordinating the landing of your commits with someone else and all the commits should land around the same time.. No, what I have is that I want to work on something but it depends on someone else's work and I w

Re: Interpreting treeherder results

On 7/12/16 1:02 AM, Mike Hommey wrote: The envisioned workflow is that you don't rebase on inbound to push, since autoland handles the landing for you. So you can keep your tree as it was before you wanted to land. OK, what about the case when A was not authored by me? What's the expected fre

Re: Interpreting treeherder results

On 7/11/16 10:10 PM, Gregory Szorc wrote: I recommend not developing on top of inbound (or fx-team or autoland) and instead basing all work on central because: This recommendation only works if your patches never depend on your own patches or on patches written by others you're working with, a

Re: Building Thunderbird : WebIDL.WebIDLError

On 9/4/14, 1:27 PM, deborah.gertrude.dig...@gmail.com wrote: The following is the content of my .mozconfig file: ac_add_options --enable-application=mail ac_add_options --enable-debug Is this a non-clobber build in an objdir in which a previous build was done with some other --enable-applicati

Re: make target for adding a mochitest?

On 4/13/14 6:17 PM, L. David Baron wrote: Is there a way to do this? I _think_ just using "mach mochitest-plain testname" will do the right thing. -Boris ___ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/d

Re: Relevance of generated .c and .cpp files in the obj-* directory for mozilla's code dependencies

On 3/3/14 9:49 AM, konstantin.sokolov.m...@gmail.com wrote: Is it somehow possible to speedup the build process by actually turning off the compilation and linkage steps to get at the generated files as quickly as possible? I believe making just the "export" target should create all the gene

Re: Relevance of generated .c and .cpp files in the obj-* directory for mozilla's code dependencies

On 2/28/14 7:46 AM, konstantin.sokolov.m...@gmail.com wrote: We wonder what the relationship is between the initial code base and these generated files. It depends. Some of these are autogenerated (from IDL) glue code for calling between JS and C++. Some are autogenerated (from IPDL) glue

Re: dom/src/events has no Makefile. How are build parameters passed to it?

On 2/3/14 4:20 PM, Alex wrote: While this is probably frowned upon, when compiling with ICC, it seems to not like BindingUtils.h at all This may well be a bug that needs fixing in BindingUtils.h. There's some SFINAE stuff in there that uses per-compiler ifdefs -Boris __