1368699 - ./mach build faster doesn't work properly without passing -purgecaches when running Firefox

Status: RESOLVED FIXED

(Firefox Build System :: General, defect, P3)

Description

[:Gijs (out for now; he/him)]

It used to be that running:

./mach build faster && ./mach run -P <whatever>

would Just Work and run with my rebuilt changes.

In the last 2-3 weeks, something changed. At first, my builds would crash all the time until the second run, somewhere in JS module loader land. That went away after a day or two.

Now, the crashes have gone away but they have been replaced by something worse: some of the time (and I honestly haven't been able to figure out when, exactly), my changes have no effect. I make changes to JS modules and the modules that run do not have those changes. I don't know how this is possible, but it's very frustrating because it ends up meaning I can't be sure that any changes are actually taking effect. The worst of it is that when I use the JS debugger to try and check, it shows the up-to-date file, meaning it *looks* as if the changes are being run, but the copy the debugger sees isn't necessarily the copy being run (and so current line indications and line breakpoints become meaningless).

./mach build faster should just work.

Comment 1

[Gregory Szorc [:gps]]

Go help us isolate this (because I'm not sure which recent changes would cause this):

* Is this with artifact builds or compiled builds?
* Does `mach build` work or is it only `mach build faster`?
* Which file(s) are you changing?
* Which platform?
* Any special mozconfig settings?

Comment 2

[Alastor Wu [:alwu]]

I got another problem is that $./mach build faster doesn't work on my OSX.

The error log is on following,

Traceback (most recent call last):
 0:01.84   File "/usr/local/Cellar/python/2.7.8_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 162, in _run_module_as_main
 0:01.84     "__main__", fname, loader, pkg_name)
 0:01.84   File "/usr/local/Cellar/python/2.7.8_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/runpy.py", line 72, in _run_code
 0:01.84     exec code in run_globals
 0:01.84   File "/Users/Alastor/mozilla-central/python/mozbuild/mozbuild/action/process_install_manifest.py", line 119, in <module>
 0:01.84     main(sys.argv[1:])
 0:01.84   File "/Users/Alastor/mozilla-central/python/mozbuild/mozbuild/action/process_install_manifest.py", line 106, in main
 0:01.84     defines=args.defines)
 0:01.84   File "/Users/Alastor/mozilla-central/python/mozbuild/mozbuild/action/process_install_manifest.py", line 69, in process_manifest
 0:01.84     remove_empty_directories=remove_empty_directories)
 0:01.84   File "/Users/Alastor/mozilla-central/python/mozbuild/mozpack/copier.py", line 399, in copy
 0:01.84     copy_results.append((destfile, f.copy(destfile, skip_if_older)))
 0:01.84   File "/Users/Alastor/mozilla-central/python/mozbuild/mozpack/files.py", line 469, in copy
 0:01.84     skip = not BaseFile.any_newer(dest.path, pp_deps)
 0:01.84   File "/Users/Alastor/mozilla-central/python/mozbuild/mozpack/files.py", line 138, in any_newer
 0:01.84     if dest_mtime < int(os.path.getmtime(input) * 1000):
 0:01.84   File "/Users/Alastor/build_mc_obj/_virtualenv/bin/../lib/python2.7/genericpath.py", line 54, in getmtime
 0:01.84     return os.stat(filename).st_mtime
 0:01.84 OSError: [Errno 2] No such file or directory: '/Users/Alastor/mozilla-central/browser/components/preferences/in-content/searchResults.xul'
 0:01.85 make: *** [install-dist/bin/browser] Error 1

Comment 3

[:Gijs (out for now; he/him)]

(In reply to Alastor Wu [:alwu][please needinfo? me] from comment #2)
> I got another problem is that $./mach build faster doesn't work on my OSX.
> 
> The error log is on following,
> 
> Traceback (most recent call last):
> <snip>
>  0:01.84 OSError: [Errno 2] No such file or directory:
> '/Users/Alastor/mozilla-central/browser/components/preferences/in-content/
> searchResults.xul'
>  0:01.85 make: *** [install-dist/bin/browser] Error 1

This feels like a separate bug. You would need to clobber for ./mach build faster to work again, because one of the files it assumes it needs was removed (either that or update the relevant .deps files by hand). I thought bug 1230060 was supposed to fix this, but maybe not for whatever type of dependency this was about, or maybe it regressed. Can you file a separate bug?

Comment 4

[Alastor Wu [:alwu]]

(In reply to :Gijs from comment #3)
> (In reply to Alastor Wu [:alwu][please needinfo? me] from comment #2)
> > I got another problem is that $./mach build faster doesn't work on my OSX.
> > 
> > The error log is on following,
> > 
> > Traceback (most recent call last):
> > <snip>
> >  0:01.84 OSError: [Errno 2] No such file or directory:
> > '/Users/Alastor/mozilla-central/browser/components/preferences/in-content/
> > searchResults.xul'
> >  0:01.85 make: *** [install-dist/bin/browser] Error 1
> 
> This feels like a separate bug. You would need to clobber for ./mach build
> faster to work again, because one of the files it assumes it needs was
> removed (either that or update the relevant .deps files by hand). I thought
> bug 1230060 was supposed to fix this, but maybe not for whatever type of
> dependency this was about, or maybe it regressed. Can you file a separate
> bug?

Ah, it could work well after running $./mach clobber.
Thanks!

Comment 5

[:Gijs (out for now; he/him)]

(In reply to Gregory Szorc [:gps] from comment #1)
> Go help us isolate this (because I'm not sure which recent changes would
> cause this):
> 
> * Is this with artifact builds or compiled builds?

Compiled builds, though I wouldn't be surprised if it happens with artifact ones, too.

> * Does `mach build` work or is it only `mach build faster`?

It seems to be intermittent. I haven't worked out what triggers this. The original issue is with `./mach build faster` not working correctly. ISTR `./mach build browser/components` had the same issue but because it's intermittent I'm having trouble isolating it to anything in particular at this point.

STR:

1. Do a full build
2. open browser/components/customizableui/PanelMultiView.jsm
3. find the handleEvent method that has:

      case "popupshowing":
        this.node.setAttribute("panelopen", "true");

and add this to the popupshowing case as the first line (ie inbetween those 2 lines):

        Cu.reportError('Look at me, opening a panel');

and save the file.

4. run ./mach build faster && ./mach run -P <extantprofile>
5. open the browser console (accel-shift-j)
6. open the panel

ER:
console gets the error message from the Cu.reportError
AR:
no error.

... but after repeating these steps a few times, it seems now everything *is* updating correctly, and I can't work out what the difference is, ie why it now works when it didn't an hour ago.

> * Which file(s) are you changing?

browser/components/customizableui/PanelMultiView.jsm

> * Which platform?

OSX, but I originally saw this on Windows. I would be surprised if it was OS-specific, though I'm aware OSX presumably uses symlinks for local builds of this file, and Windows won't.

> * Any special mozconfig settings?

Nope:

> mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../builds/opt/
> 
> ac_add_options --enable-warnings-as-errors


is all of my mozconfig.

Comment 6

[Gregory Szorc [:gps]]

Thanks for the info, Gijs. It's very helpful.

Your mozconfig is simple, which is good.

PanelMultiView.jsm is part of EXTRA_JS_MODULES, which has simple semantics as far as the build system goes. Combined with the fact that you can reproduce this on both Windows and OS X is... alarming. The build mechanism here is pretty basic and AFAIK there haven't been significant changes in this area recently.

You've said -purgecaches makes the problem go away. To me, that says that the build system is putting the bits in the right places but Firefox is using old, cached bits.

If you can isolate this to -purgecaches fixing the problem without running a build in between, then I'm fairly confident the bug is in the cache and not the build system. Now, we /may/ need a workaround in the build system to touch a file or something. But someone who understands the cache will need to weigh in.

The modules page says Nathan Froyd is module owner for XPCOM. So let's see what he says.

Comment 7

[Nathan Froyd [:froydnj]]

Looks like -purgecaches controls things like:

http://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#2765

Which suggests that the startup cache is caching too much?...but only sometimes, because Gijs can't reproduce the problem anymore?

I don't think this is a build system problem.  Gijs, are you able to bisect this at all?

Comment 8

[Mike Hommey [:glandium]]

So, there's one thing that is build system related:

https://dxr.mozilla.org/mozilla-central/source/config/rules.mk#1605-1609
These rules create a dist/bin/.purgecaches file.

And the startup code that tries to use that file picks it up in the application directory:
https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#237
https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#4126-4133

For Firefox, the application directory is dist/bin/browser, not dist/bin.

A similar bug was bug 790115 for metro, and it's bug 755724 that actually broke this by not adjusting the .purgecaches touching code to add dist/bin/browser to the list.

Comment 9

[:Felipe Gomes (needinfo for replies!)]

This happened in the past and was fixed, see bug 1211957 comment 4

Comment 10

[:Gijs (out for now; he/him)]

(In reply to Nathan Froyd [:froydnj] from comment #7)
> Looks like -purgecaches controls things like:
> 
> http://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.
> cpp#2765
> 
> Which suggests that the startup cache is caching too much?...but only
> sometimes, because Gijs can't reproduce the problem anymore?
> 
> I don't think this is a build system problem.  Gijs, are you able to bisect
> this at all?

Nope. :-(

Locally, things have so far gone back to normal... but I have no idea why / how to check what was happening before.

Comment 11

[:Gijs (out for now; he/him)]

I'm just seeing this happening again now, this time with browser/extensions/pocket/bootstrap.js .

(In reply to Mike Hommey [:glandium] from comment #8)
> So, there's one thing that is build system related:
> 
> https://dxr.mozilla.org/mozilla-central/source/config/rules.mk#1605-1609
> These rules create a dist/bin/.purgecaches file.
> 
> And the startup code that tries to use that file picks it up in the
> application directory:
> https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.
> cpp#237
> https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.
> cpp#4126-4133
> 
> For Firefox, the application directory is dist/bin/browser, not dist/bin.
> 
> A similar bug was bug 790115 for metro, and it's bug 755724 that actually
> broke this by not adjusting the .purgecaches touching code to add
> dist/bin/browser to the list.

gijs-mbp:firefox-unified gkruitbosch$ ls ../builds/opt/dist/bin/browser/.purgecaches
ls: ../builds/opt/dist/bin/browser/.purgecaches: No such file or directory
gijs-mbp:firefox-unified gkruitbosch$ ls ../builds/opt/dist/bin/.purgecaches
ls: ../builds/opt/dist/bin/.purgecaches: No such file or directory
gijs-mbp:firefox-unified gkruitbosch$ ls ../builds/opt/dist/.purgecaches
ls: ../builds/opt/dist/.purgecaches: No such file or directory


./mach run is running from that dir:

gijs-mbp:firefox-unified gkruitbosch$ ./mach run -P trunk
 0:00.25 /Users/gkruitbosch/dev/builds/opt/dist/Nightly.app/Contents/MacOS/firefox -P trunk -no-remote -foreground


gijs-mbp:firefox-unified gkruitbosch$ find ../builds/opt/dist/ -iname '.purgecaches'

returns nothing.

I can rerun with ./mach run multiple times, and the updated file is still not read. If I open the browser toolbox, it shows the updated file, but when stepping through it with the debugger, it is clear that the lines I added are not really being executed by the JS engine (the highlighted lines are offset by the number of lines I added, and so it highlights commented out lines etc.).

Comment 12

[:Gijs (out for now; he/him)]

Last ./mach build faster output:

gijs-mbp:firefox-unified gkruitbosch$ ./mach build faster && ./mach run -P trunk
 0:00.32 /usr/bin/make -C /Users/gkruitbosch/dev/builds/opt -j8 -s backend
 0:00.48 /usr/bin/make -C faster -j8 -s
 0:00.66 source-repo.h
 0:00.67 buildid.h
 0:00.81 Elapsed: 0.04s; From dist/idl: Kept 1095 existing; Added/updated 0; Removed 0 files and 0 directories.
 0:01.36 application.ini
 0:01.55 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/gmp-clearkey/0.1: Kept 0 existing; Added/updated 1; Removed 0 files and 0 directories.
 0:01.55 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/gmp-fake/1.0: Kept 2 existing; Added/updated 0; Removed 0 files and 0 directories.
 0:01.55 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/[e-mail]: Kept 1 existing; Added/updated 1; Removed 0 files and 0 directories.
 0:01.55 Elapsed: 0.01s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/[e-mail]: Kept 31 existing; Added/updated 1; Removed 0 files and 0 directories.
 0:01.56 Elapsed: 0.01s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/[e-mail]: Kept 55 existing; Added/updated 3; Removed 0 files and 0 directories.
 0:01.57 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/gmp-fakeopenh264/1.0: Kept 2 existing; Added/updated 0; Removed 0 files and 0 directories.
 0:01.78 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/[e-mail]: Kept 2 existing; Added/updated 1; Removed 0 files and 0 directories.
 0:01.78 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/[e-mail]: Kept 20 existing; Added/updated 1; Removed 0 files and 0 directories.
 0:01.78 Elapsed: 0.01s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/[e-mail]: Kept 29 existing; Added/updated 1; Removed 0 files and 0 directories.
 0:01.78 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/[e-mail]: Kept 3 existing; Added/updated 2; Removed 0 files and 0 directories.
 0:01.78 Elapsed: 0.01s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/[e-mail]: Kept 12 existing; Added/updated 3; Removed 0 files and 0 directories.
 0:01.79 Elapsed: 0.01s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/[e-mail]: Kept 34 existing; Added/updated 1; Removed 0 files and 0 directories.
 0:01.81 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/features/[e-mail]: Kept 4 existing; Added/updated 2; Removed 0 files and 0 directories.
 0:01.91 Elapsed: 0.00s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}: Kept 0 existing; Added/updated 2; Removed 0 files and 0 directories.
 0:02.32 Elapsed: 0.41s; From /Users/gkruitbosch/dev/builds/opt/dist/bin: Kept 1603 existing; Added/updated 65; Removed 0 files and 0 directories.
 0:02.33 Elapsed: 0.77s; From /Users/gkruitbosch/dev/builds/opt/dist/bin/browser: Kept 2886 existing; Added/updated 92; Removed 0 files and 0 directories.
 0:03.49 Overall system resources - Wall time: 3s; CPU: 50%; Read bytes: 3359232; Write bytes: 38313472; Read time: 49; Write time: 432
 0:03.49 Swap in/out (MB): 1/0
 0:03.50 Your build was successful!
To view resource usage of the build, run |mach resource-usage|.
 0:00.23 /Users/gkruitbosch/dev/builds/opt/dist/Nightly.app/Contents/MacOS/firefox -P trunk -no-remote -foreground

Comment 13

[:Gijs (out for now; he/him)]

Some observations:

- after adding .purgecaches files in dist/, dist/bin/ and dist/bin/browser, and restarting (but not rerunning ./mach build of any kind), nothing happens. Still broken.
- after then once rerunning ./mach build faster, things work and files are updated. Note that at this point, the .purgecaches files were added to the mac app bundle (they weren't before):

    gijs-mbp:firefox-unified gkruitbosch$ find ../builds/opt/dist/ -iname '.purgecaches'
    ../builds/opt/dist//.purgecaches
    ../builds/opt/dist//bin/.purgecaches
    ../builds/opt/dist//bin/browser/.purgecaches
    ../builds/opt/dist//Nightly.app/Contents/Resources/.purgecaches
    ../builds/opt/dist//Nightly.app/Contents/Resources/browser/.purgecaches 

- after that, when updating pocket's bootstrap.js, I don't need to even rerun ./mach build because the file is symlinked in, and at this point nightly re-reads it every time, it seems.
- if I remove the .purgecaches files and re-run ./mach build faster, the above 'find' command returns no files again, and things are broken again.


Finally, things in comment #11 started after a clobber build and a series of ./mach build faster builds. Not sure anymore if things updated at all between the clobber and the point where things failed, but the clobber build was done yesterday and then went unused until this morning. Also, in case it matters, this profile ('trunk') gets reused for regular nightly builds when I want to test something against vanilla mozilla-produced nightly, which seems to trigger bug 1371273, which may or may not be related.

Comment 14

[Nick Alexander :nalexander [he/him]]

Attachment: Bug 1368699 - Pre: Remove MY_{CONFIG,RULES} Makefile customization hooks.

I very much doubt these are used, but even if we are -- we shouldn't
support this type of local customization, since it doesn't extend to
non-Make-based backends.

With the customization point removed, there's no way to set ETAGS, so
we remove what little support there was for generating Emacs tags.

Review commit: https://reviewboard.mozilla.org/r/214402/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/214402/

Comment 15

[Nick Alexander :nalexander [he/him]]

Attachment: Bug 1368699 - Write .purgecaches sentinels every |mach build|.

This adds a new `postbuild` step to each `BuildBackend`
implementation, and uses it to write .purgecaches after every |mach
build| invocation -- including after |mach build TARGET| invocations.
This approach should be more robust than the existing recursive-Make
based solution, which seems to not write the .purgecaches files in
some situations.

In addition, the recursive-Make solution does not generalize to other
backends, in particular Tup.  It is possible that the Tup backend will
handle writing the .purgecaches sentinel as part of its regular build
process, but discussions with mshal suggest that there's no convenient
way for Tup to write .purgecaches only when something *changes* during
the build.  That is, Tup can achieve the behaviour implemented by this
patch, but it's not easier to do better by not writing .purgecaches
when the caches do not in fact need to be purged.

I elected to bake in the special knowledge of
--enable-application=browser and macOS here since this whole process
is special.  If we need to generalize, we could add a moz.configure
option specifying the purgecaches directories, but it doesn't seem
worth it right now.

This will require tweaking as we migrate the macOS bundle handling to
moz.build, especially in browser/app.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=1223748, which could
improve this significantly.

Review commit: https://reviewboard.mozilla.org/r/214404/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/214404/

Comment 16

[Nick Alexander :nalexander [he/him]]

Attachment: Bug 1368699 - Post: Remove PURGECACHES from Make and now-unused app-rules.mk.

Now that writing the .purgecaches sentinel is done by |mach build|, we
can remove it from Make.  In addition, we can cull the now-unused
app-rules.mk \o/

Review commit: https://reviewboard.mozilla.org/r/214406/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/214406/

Comment 17

[Gregory Szorc [:gps]]

The patches on this bug are all in the build system. Moving component.

Comment 18

[Gregory Szorc [:gps]]

Comment on attachment 8944088 [details]
Bug 1368699 - Pre: Remove MY_{CONFIG,RULES} Makefile customization hooks.

https://reviewboard.mozilla.org/r/214402/#review220394

Further evidence this feature is unused: no entries for these files in .hgignore or .gitignore. I would hope that if people were using this, they'd be tired of seeing untracked files in their repos and would have submitted a patch to the ignore files.

Comment 19

[Gregory Szorc [:gps]]

Comment on attachment 8944089 [details]
Bug 1368699 - Write .purgecaches sentinels every |mach build|.

https://reviewboard.mozilla.org/r/214404/#review220396

I think this needs some work before r+.

Thank you for the detailed history in the commit message. I would have asked questions like "why not in the build backend" as part of review if the context weren't there.

I'm OK with this functionality living in the build backend and only called from `mach build`. There's a slight chance some people are still not using `mach build`. But we've said for a while that we don't really support building outside the context of `mach`. So I'm fine with this direction.

::: python/mozbuild/mozbuild/backend/base.py:225
(Diff revision 1)
> +        app = config.substs['MOZ_BUILD_APP']
> +        if app == 'browser':
> +            root = mozpath.join(config.topobjdir, 'dist', 'bin', 'browser')
> +
> +        purgecaches_dirs = [root]
> +        if app == 'browser' and 'cocoa' == config.substs['MOZ_WIDGET_TOOLKIT']:

Why are we limiting this to the `browser` app? Can we not use e.g. `dist/bin/${MOZ_BUILD_APP}/`?

::: python/mozbuild/mozbuild/backend/base.py:238
(Diff revision 1)
> +                                     'Contents', 'Resources',
> +                                     'browser')
> +            purgecaches_dirs.append(bundledir)
> +
> +        for dir in purgecaches_dirs:
> +            ensureParentDir(dir)

It feels wrong that we have to `ensureParentDir` here. I think a better solution is to only call this code after a successful build. If the directory doesn't exist after successful build, let the exception be raised. That will help find logic errors and prevent us from accidentally creating `.purgecaches` files when we shouldn't be.

::: python/mozbuild/mozbuild/backend/base.py:242
(Diff revision 1)
> +        for dir in purgecaches_dirs:
> +            ensureParentDir(dir)
> +            with open(mozpath.join(dir, '.purgecaches'), 'wt') as f:
> +                f.write('\n')
> +
> +    def postbuild(self, config, output, jobs, verbose, status):

Let's rename this to `post_build`.

::: python/mozbuild/mozbuild/controller/building.py:1088
(Diff revision 1)
> +            except Exception as ex:
> +                self.log(logging.DEBUG, 'postbuild', {'ex': ex},
> +                         "Unable to run active build backend's post-build step: {ex}.")

If the post build step raises, I think we should ensure the exit code is non-0. What do you think?

Comment 20

[Gregory Szorc [:gps]]

Comment on attachment 8944090 [details]
Bug 1368699 - Post: Remove PURGECACHES from Make and now-unused app-rules.mk.

https://reviewboard.mozilla.org/r/214406/#review220400

Good riddance.

Comment 21

[Mike Hommey [:glandium]]

(In reply to Gregory Szorc [:gps] from comment #19)
> Why are we limiting this to the `browser` app? Can we not use e.g.
> `dist/bin/${MOZ_BUILD_APP}/`?

What is /really/ wanted is to use the FINAL_TARGET as per the MOZ_BUILD_APP directory. Which in the case of browser/ is dist/bin/$MOZ_BUILD_APP, and in the case of about every other app, is dist/bin.

Comment 22

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8944088 [details]
Bug 1368699 - Pre: Remove MY_{CONFIG,RULES} Makefile customization hooks.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/214402/diff/1-2/

Comment 23

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8944089 [details]
Bug 1368699 - Write .purgecaches sentinels every |mach build|.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/214404/diff/1-2/

Comment 24

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8944090 [details]
Bug 1368699 - Post: Remove PURGECACHES from Make and now-unused app-rules.mk.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/214406/diff/1-2/

Comment 25

[Gregory Szorc [:gps]]

Comment on attachment 8944088 [details]
Bug 1368699 - Pre: Remove MY_{CONFIG,RULES} Makefile customization hooks.

https://reviewboard.mozilla.org/r/214402/#review222436

Comment 26

[Gregory Szorc [:gps]]

Comment on attachment 8944089 [details]
Bug 1368699 - Write .purgecaches sentinels every |mach build|.

https://reviewboard.mozilla.org/r/214404/#review222438

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7297a1e8c4ff
Pre: Remove MY_{CONFIG,RULES} Makefile customization hooks. r=gps
https://hg.mozilla.org/integration/autoland/rev/35a5db01b6ae
Write .purgecaches sentinels every |mach build|. r=gps
https://hg.mozilla.org/integration/autoland/rev/e16fc8abd345
Post: Remove PURGECACHES from Make and now-unused app-rules.mk. r=gps

Comment 28

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/7297a1e8c4ff
https://hg.mozilla.org/mozilla-central/rev/35a5db01b6ae
https://hg.mozilla.org/mozilla-central/rev/e16fc8abd345

Comment 29

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/5454ed95c82a
Backed out 3 changesets for bustage on Android L10n nightlies a=backout

Comment 30

[Cristina Coroiu [:ccoroiu]]

Backed out 3 changesets (bug 1368699) for bustage on Android L10n nightlies a=backout 

Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=159439571&repo=mozilla-central&lineNumber=1486

Backout: https://hg.mozilla.org/mozilla-central/rev/5454ed95c82a956009db2f4b04d008ec8753e61e

Comment 31

[Jim Jeffery not reading bug-mail 1/2/11]

Does this need to be REOPENED due to backout ?

Comment 32

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8944088 [details]
Bug 1368699 - Pre: Remove MY_{CONFIG,RULES} Makefile customization hooks.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/214402/diff/2-3/

Comment 33

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8944089 [details]
Bug 1368699 - Write .purgecaches sentinels every |mach build|.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/214404/diff/2-3/

Comment 34

[Nick Alexander :nalexander [he/him]]

Comment on attachment 8944090 [details]
Bug 1368699 - Post: Remove PURGECACHES from Make and now-unused app-rules.mk.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/214406/diff/2-3/

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a67ac1c9a5a7
Pre: Remove MY_{CONFIG,RULES} Makefile customization hooks. r=gps
https://hg.mozilla.org/integration/autoland/rev/c3b34905b9c9
Write .purgecaches sentinels every |mach build|. r=gps
https://hg.mozilla.org/integration/autoland/rev/633e0fd655b8
Post: Remove PURGECACHES from Make and now-unused app-rules.mk. r=gps

Comment 36

[Nick Alexander :nalexander [he/him]]

OK, here's what happened: l10n repacks for Android call |mach configure && mach build buildid.h && mach build config/export| directly.  That's not expected to work -- it's expected that |mach build| is the first thing after |mach configure| -- and I'm confident that the expected directory isn't in place, failing the build step.  That was Greg's preference in his review (https://bugzilla.mozilla.org/show_bug.cgi?id=1368699#c19), and I think it's the right thing to do.  It just gets in the way here.

Rather than addressing this more generally, I just opted out of .purgecaches sentinels for mobile/android entirely.  That's correct enough, and fixes this issue. 

It doesn't address Desktop l10n repacks, but they're snowflakes for other reasons: l10n repacks for Desktop call |make -C ... buildid.h| so they don't feel this pain.


I have a try build with a green l10n repack at https://treeherder.mozilla.org/#/jobs?repo=try&author=[e-mail]&selectedJob=159622877, so I'm relanding.

Comment 37

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/a67ac1c9a5a7
https://hg.mozilla.org/mozilla-central/rev/c3b34905b9c9
https://hg.mozilla.org/mozilla-central/rev/633e0fd655b8