Now that the VisualStudio backend will no-op if nothing has changed, it
should be safe to always run this backend.
On first run, backend generation takes ~3.5s on my machine. On subsequent run,
it takes ~1.5s. Wall time for a no-op config.status is now ~15.7s. We could like
make the Visual Studio backend faster by not writing so many project files.
But this would require consolidating libraries in moz.build files. And that's
out of scope for this change.
MozReview-Commit-ID: 5W38HMGmcuV
--HG--
extra : rebase_source : 1164621e00e2b917b5462d5ba310e0cc94d23bd9
There is probably a way to dynamically retrieve the version. But rather
than take the chance we'd query the wrong thing, let's just parse the
version that Visual Studio writes to the solution file when saving it and
use it.
With this change, generating the VisualStudio build backend should not change
any files unless the build config has changed. This means we can generate
Visual Studio files at will without causing Visual Studio to complain
about the solution and other files changing and needing reloading.
MozReview-Commit-ID: 1udZ72SLEzP
--HG--
extra : rebase_source : d15bff5b30a021dc1180e48fb7bb0d6c84871b69
Visual Studio will write this variable to an ancient Visual Studio
version (2010 I believe) if we don't specify it. Explicitly write the
variable to the minimum Visual Studio version we support.
MozReview-Commit-ID: 8Y0im48OM2G
--HG--
extra : rebase_source : 7b1f4cfe778c6258dce068b2aec8b6acd8e85102
Upon further examination, VS2013 and VS2015 share the same file format
version. They also write the internal version number in a comment, not
the user-facing production version.
MozReview-Commit-ID: 92HB0pEzeI6
--HG--
extra : rebase_source : ebf00ae704ccd44415f8d7054359c87287734926
We've audited this code, so the calls inside the closure should
be panic-free. Meanwhile the thread join() itself seems to be
panicing on windows. This will at least get us a more obvious
crash.
MozReview-Commit-ID: JXoDOOu2x0K
--HG--
extra : rebase_source : 661da4e8e8dc98e25b318a51c49a406ee86beb46
Recent changes to mozharness in bug 1270317 started using pooled shared
storage for Mercurial repos. This means the "default" path in Mercurial
repos is variable depending on which repo was the first to be built on
a machine.
By default, the Firefox build system resolves the source repository
from `hg paths default`. This is now incorrect default behavior in
automation.
We fix the regression by setting MOZ_SOURCE_REPO in the environment to
path to the repository that mozharness is currently building.
MozReview-Commit-ID: 34IPf7PJfuA
--HG--
extra : rebase_source : d0d717847f1e52444ecd53ddf16716bad42809eb
extra : source : a2a4c06d9736850782d8cc52802e0207ca1bf27a
Previously, we required both or none of MOZ_SOURCE_REPO and
MOZ_SOURCE_CHANGESET to be defined. This logic was established in
51029f4d82d3 (bug 1247162).
There appears to be no good reason why we require MOZ_SOURCE_CHANGESET
if MOZ_SOURCE_REPO is defined. After all, if we have a checkout we should
be able to resolve the revision.
This commit changes the logic to resolve the changeset when not defined.
We still error if MOZ_SOURCE_REPO is defined but we can't resolve the
changeset. I can't imagine this breaking anything.
This change will be necessary to appease TaskCluster tasks once mozharness
is changed in a subsequent commit to define MOZ_SOURCE_REPO. Buildbot and
TC each have their own way of specifying the source revision. Rather than
change mozharness, it feels easier to just have the build system derive
things. This decision is further justified by the fact there is a chicken
and egg problem in mozharness: the environment variable dict is resolved
before source directory population. So, we'd need to teach mozharness
about TC's VCS mechanism, which it currently has no knowledge of. I'd rather
not do that.
MozReview-Commit-ID: ANaoGbPGWj2
--HG--
extra : rebase_source : fd09b282dc1d88478eb76e37796b210cccecaf3a
Older versions of Python 2.7 have a bug where subprocess and execve
don't like unicode in the environment variable dict. This patch
ensures we are using a str.
Pusing on a CLOSED TREE like a boss.
--HG--
extra : amend_source : 5f464f6ffd58711d31129e6d8971a85b5b75b1c7