In bug 1329858 we found out that during test packaging, where we currently build the gtest libxul, we were rebuilding the regular libxul as well. This seems to be due to some weirdness with the Apple ar we're using. bug 1200311 is going to make that go away in automation, which is good, but glandium pointed out that we also run `$(MAKE) -C $(DEPTH)/browser/app repackage` on Mac to sync the newly-built gtest libxul into the app package. This is a bit of overkill, we could just symlink the file to the right place instead. This happens in this Makefile: https://dxr.mozilla.org/mozilla-central/source/testing/gtest/Makefile.in Although honestly, I would suggest just moving both of those commands directly into the mach command implementation: https://dxr.mozilla.org/mozilla-central/rev/1d025ac534a6333a8170a59a95a8a3673d4028ee/python/mozbuild/mozbuild/mach_commands.py#896 Right now we effectively run `make -C testing/gtest gtest`. We could instead run `make -C toolkit/library/gtest BUILD_GTEST=1` and then if we're on OS X symlink the file into the app bundle.
Please, can you fix this? It doesn't even try incremental linking on windows, so it takes 2 minutes...
This bug, as filed, is for a mac-only problem, most of which was fixed in bug 1200311. If you're seeing a problem on Windows can you file a new bug for that?
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #2) > This bug, as filed, is for a mac-only problem, most of which was fixed in > bug 1200311. If you're seeing a problem on Windows can you file a new bug > for that? Bug 1341636
You need to log in before you can comment on or make changes to this bug.