The config.guess file is checked into source control. I'm not sure
under what conditions we wouldn't fail to find this file. So the
$(wildcard) shouldn't be necessary.
MozReview-Commit-ID: KCctPFW3Eab
--HG--
extra : rebase_source : 2b9f674bdffc95ac4e1999f9a5d8b7ffa13e8d74
This likely became unused with the port to moz.configure.
MozReview-Commit-ID: FoIDg6Q2K4J
--HG--
extra : rebase_source : 1dd55aebaeae9d9e7d4704d13c86c4a545a72165
moz.configure invokes autoconf to generate old-configure. As part of this
it checks mtimes of dependencies. The logic in client.mk is old and
redundant. So remove it.
MozReview-Commit-ID: FG2lWiIjKqV
--HG--
extra : rebase_source : 779a7ffb076ce15a76fe2e675695943d43c5c454
We don't want to encourage people to use client.mk.
MozReview-Commit-ID: 53uLrINdHJE
--HG--
extra : rebase_source : ad96b67e867d7574f54475599a0c744df7eaa5e0
This was mainly used to support Universal MacOS builds, which were
removed several months ago.
In theory, someone could be using this feature to build multiple
applications with one build system invocation. But given that client.mk
is no longer the preferred interface to the build system and multiple
applications can be built by running `mach build` with different
mozconfigs, I don't think support for this feature is worth keeping.
This commit removes support for MOZ_BUILD_PROJECTS and related
functionality from client.mk. Support for recognizing
MOZ_CURRENT_PROJECT in configure and mozconfig evaluation has also
been removed. This includes support for the ac_add_app_options
mozconfig function.
Good riddance.
MozReview-Commit-ID: 7xI2jYxDFFr
--HG--
extra : rebase_source : 91068f3b8ae32fbcda4defb5d4bb086a04387598
These variables are unused in the repo. The %_ALL variation is used for
sccache, however.
The last use of these variables was removed when support for MacOS
universal builds was removed.
Someone somewhere may be relying on this functionality. But I don't
think it is worth continuing to support in client.mk. If someone
really needs it, we can reintroduce support for the feature elsewhere,
like in mach or via mozconfig support somehow.
MozReview-Commit-ID: 4KznCmK3JTN
--HG--
extra : rebase_source : 656008f9b4264768a2127fcffdb2ab28ff92991f
There are no references to this variable outside client.mk. AFAICT
it is unused.
The only reasonable justification for retaining this support IMO was
Universal MacOS builds. And those are no longer supported.
MozReview-Commit-ID: 9MnC18Bd1ge
--HG--
extra : rebase_source : 16c96dfceffb89434489b79f3f4ca2c48506840f
It has not been useful since we removed the possibility to build in the
source directory.
--HG--
extra : rebase_source : 479100785c8253ea3e255ebbda4b3538e8ed33ff
The topobjdir-finding logic in mozbuild relies on MOZ_CURRENT_PROJECT
being set, and it's currently only set when going through client.mk.
On automation, during universal builds, make check is invoked directly
in one of the objdirs, so MOZ_CURRENT_PROJECT is not set. We've had
other similar problems in the past. Ensuring MOZ_CURRENT_PROJECT is set
in the objdir itself should reduce the risk of other such issues in the
future.
Killing the sccache background daemon is part of postflight_all, but in
the current setup, postflight_all happens at the end of a "normal" build,
but we run automation build steps after that.
What happens then is that more compilations happen (gtests), which start
sccache again, but there's nothing to kill sccache again once this is
all done.
Now that the OSX universal builds postflight is gone, it is not
necessary for postflight_all to happen before the automation build steps.
So ensure postflight_all scripts happen last.
The downside of this change is that this now prevents sccache.log from
being uploaded, but we should probably send processed data to the graph
server instead.
Killing the sccache background daemon is part of postflight_all, but in
the current setup, postflight_all happens at the end of a "normal" build,
but we run automation build steps after that.
What happens then is that more compilations happen (gtests), which start
sccache again, but there's nothing to kill sccache again once this is
all done.
Now that the OSX universal builds postflight is gone, it is not
necessary for postflight_all to happen before the automation build steps.
So ensure postflight_all scripts happen last.
The downside of this change is that this now prevents sccache.log from
being uploaded, but we should probably send processed data to the graph
server instead.
The configure.in is a small wrapper around python configure, that is
still a m4 script so that people running autoconf manually can still
do so without breaking their stuff (and we have jobs that do that
on automation as well).
But considering how simple the m4 is, to avoid having the autoconf
checking code twice (once in client.mk and once in
build/moz.configure/old.configure), we can just process it with sed
instead of autoconf.
This will enable each PGO phase to show up in mach's resource reporting,
making it easier to compare PGO runtime across machines. This does
confuse the rendering of `mach resource-usage` a bit since it doesn't
know how to handle overlapping tiers. But the raw data is captured as
expected. I don't think `mach resource-usage` is that heavily used right
now, so I don't care about a minor regression for PGO builds.
MozReview-Commit-ID: HalvEwITmif
--HG--
extra : rebase_source : 5c27c6bda814cd61c0da792d9336980dc4f530a9
The way UPLOAD_EXTRA_FILES is currently exported makes the files added
to the list added in each directory that is being traversed recursively
because of the += in .mozconfig.mk, combined with "export".
The easy way out is to remove the export altogether, but being unsure of
the side effects of putting all non exported mk_add_options variables
in .mozconfig.mk, limit this to UPLOAD_EXTRA_FILES.
This adds a format option to mach environment and uses it in client.mk to
create a .mozconfig.json in the objdir, containing all the relevant data
from mozconfig. If the mozconfig doesn't change in a way that alters that
data, we still skip configure.
At the same time, use mach environment in place of mozconfig2configure and
mozconfig2client-mk, which makes us now have only one mozconfig reader.
Also, in the mozconfig reader, keep track of environment variables (as
opposed to shell variables), so that changes such as a variable that was
exported not being exported anymore is spotted. At the opposite, in order
for irrelevant environment variable changes not to incur in re-running
configure, only a set of environment variables are stored when they are
unmodified. Otherwise, changes such as using a different terminal window,
or even rebooting, would trigger reconfigures.
Finally, make mach environment emit both MOZ_OBJDIR and OBJDIR for
client.mk, and cleanup some objdir-related things in client.mk..
At the same time, make the mozconfig reader take MOZ_OBJDIR from the
environment if it is defined there and not in the mozconfig.
To avoid surprises for devs building locally, auto clobbering is now opt-in, via
the use of |mk_add_options AUTOCLOBBER=1| in the mozconfig. Our automation uses
build/mozconfig.common which specifies this, so auto clobber will remain enabled
for our buildbot machines.
Now log in a single file given by the MOZ_JAR_LOG_FILE environment variable.
Log entries contain the URI of the Zip archive, followed by the path in the
archive.
* * *
Bug 840094 - Fixup for debug builds failure because of nsZipArchive::CloseArchive being called several times
1. mozconfig2client-mk still refers to $HOME/.mozconfig, even though we
removed it a while ago. Thanks to Neil for pointing it out.
2. MOZCONFIG_FIND and MOZCONFIG_MODULES are no longer used by client.mk.
3. Make CONFIG_GUESS a script that runs just once per client.mk invocation.
--HG--
extra : rebase_source : ec75ebcc5cea004f64abafb8a219e828234237de
* Switches js-config generation to use $MAKE rather than $GMAKE, since using
make.exe on pymake builds causes issues:
"config/autoconf.mk:354: *** Windows-style srcdir being used with GNU make"
* Ensures $MAKE is defined for configure when using client.mk
* For standalone js builds client.mk won't be used, so sets $MAKE manually if it
isn't already defined, to avoid bug 605133 comment 22.
Gregory Szorc
Chris Manchester
Mike Hommey
Carsten "Tomcat" Book
Sylvestre Ledru
Arnaud Sourioux
Brian Smith
Wes Kocher
Mike Shal
Gabriele Svelto
Cykesiopka
Alexandros Chronopoulos
Ed Morley
Ryan VanderMeulen
Jeff Hammel
Benoit Girard
Ehsan Akhgari
Siddharth Agarwal
Gervase Markham
John O'Duinn
Steve Fink
Joey Armstrong
Joey Armstrong
Nicholas Nethercote
mh
Justin Lebar
Ed Morley
Chris AtLee
Neil Rashbrook
Kyle Huey