Originally, the changes to FakeCompiler allowing overlays was meant to
be used for compiler target platform, but it turns out the
simplifications this allows on the compiler definitions themselves are
nice.
We use _pretty_path when specifying the targets of generated files, so
we need to use _pretty_path for the inputs as well. Otherwise make won't
know that they refer to the same file, and result in "No rule to make
target" errors.
MozReview-Commit-ID: JTdLFbkX1J0
Some generated files will depend on other generated files, but still
need to be in the export tier because they are C++ headers.
MozReview-Commit-ID: AFvp92lF0xy
- enable debug artifact from a mozconfig file based on MOZ_DEBUG environment variable
- OSX debug artifact builds have 'mac64' instead of 'mac' into their file name
(fix debug artifact build download on OSX)
MozReview-Commit-ID: 7kAvsTfwaCb
--HG--
extra : transplant_source : %E6v%25%B79M%02%7E%A9%8B%FF%24%03%D1%BDo%AB%0F%B49
Because some older python 2.7 versions throw bogus errors when using the
exec statement as a function, use the function we added in bug 1264831
everywhere we use exec in the various configure tests. It doesn't take
much to trigger them, and the following changes ends up doing exactly
that.
Our current build system support for Rust compiles any Rust crate into a
so-called staticlib, which is a static library (.a file) that includes
the Rust runtime. That staticlib is then linked into libxul. For
supporting multiple crates, this approach breaks down, as linking
multiple copies of the Rust runtime is going to fail.
For supporting multiple crates, the approach taken here is to compile
each crate into a so-called rlib, which is essentially a staticlib
without the Rust runtime linked in. The build system takes note of
every crate destined for linking with libxul (treating them like static
libraries generated from C/C++ files), and generates a super-crate,
whimsically named "rul", that is compiled as a staticlib (so as to
include the Rust runtime) and then linked into libxul. Thus only one
copy of the Rust runtime is included, and the Rust compiler can take
care of any inter-crate dependencies.
This patch currently only supports Rust code in shared libraries, not in
binaries.
The format provided to the build system by the manifest parser is highly redundant:
every test lists all variables for that test, and many tests use a large
support-files entry in DEFAULT that ends up in individual test objects. This
patch stores these DEFAULTS per-manifest rather than per-test to save disk
space, resulting in about a ~22mb smaller all-tests.json file. The
in-memory representation of tests is not changed by this patch, as the defaults
are again propagated to individual tests as all-tests.json is read by the test
resolver.
MozReview-Commit-ID: CEJaevfS5s7
imply_option has no effect when the resolved value is None, so the same
logic can be applied when checking for unknown implied options.
This allows to imply options that may not always exist (because they are
in a configure file that is optionally included).
Ideally, it would be better not to do this, but until we have something
better than optionally included configure files for
--disable-compile-environment, this is a necessary evil.
So far, everything was essentially executed at "declaration". This
made the sandbox code simpler, but to improve on the tooling around
python configure (for tests and introspection), we need to have more
flexibility, which executing everything at declaration doesn't give.
With this change, only @depends functions depending on --help, as
well as templates, are executed at the moment the moz.configure
files are included in the sandbox. The remainder is executed at the
end.
Whether it uses locale._parse_localename or nl_langinfo makes it have completely
different results in weird and/or widespread locale settings (LC_ALL=UTF-8 or
LC_ALL=C).
Check if the INSIDE_EMACS environment variable is set and change the
log level to WARNING to not confuse the emacs/mi with logging messages.
MozReview-Commit-ID: 5AWZ6swGJsE
--HG--
extra : transplant_source : b%24%8Ff6%968%8A%02%E2%07%DD%C6Y9E%CB%7C.%E4
This requires a change to how we process test manifests in the build system:
now, whenever we see a support file mentioned in a manifest, we require that
file isn't already in that test's support files, but if we see a support file
that was already seen in some other test, the entry is ignored, but it is not
an error. As a result of this change, several duplicate support-files entries
needed to be removed.
MozReview-Commit-ID: G0juyxzcaB8
--HG--
rename : testing/mozbase/manifestparser/tests/test_default_skipif.py => testing/mozbase/manifestparser/tests/test_default_overrides.py
Our current build system support for Rust compiles any Rust crate into a
so-called staticlib, which is a static library (.a file) that includes
the Rust runtime. That staticlib is then linked into libxul. For
supporting multiple crates, this approach breaks down, as linking
multiple copies of the Rust runtime is going to fail.
For supporting multiple crates, the approach taken here is to compile
each crate into a so-called rlib, which is essentially a staticlib
without the Rust runtime linked in. The build system takes note of
every crate destined for linking with libxul (treating them like static
libraries generated from C/C++ files), and generates a super-crate,
whimsically named "rul", that is compiled as a staticlib (so as to
include the Rust runtime) and then linked into libxul. Thus only one
copy of the Rust runtime is included, and the Rust compiler can take
care of any inter-crate dependencies.
This patch currently only supports Rust code in shared libraries, not in
binaries. The handling for the rul crate is placed in the common
backend, with a special hook for derived backends to handle shared
library objects.
When reading config.log, with old-configure output, we may get non-ascii
strings, but that currently fails because we're using plain open() to
read it. So use encoded_open() instead (which does the same job for
other files in the same script).
Because the build system can be encapsulated in mach, python configure
can have a pipe as stdout/stderr, and in that case, sys.stdout/stderr
have an ascii encoding, failing to print out anything that doesn't
fit in ascii, consequently failing to print the things we've read from
config.log. So reopen stdout and stderr with the right encoding in
the configure output handler.
This moves test installation for test files out of the monolithic install
manifest for $objdir/_tests, and determines the test and support files
to install based on the object derived from all-tests.json. Additionally,
the files resulting from TEST_HARNESS_FILES are installed, as some tests
will depend on them.
As a result, the time to install tests when invoking the test runner will
scale with the number of tests requested to run rather than the entire set
of tests in the tree, resulting in significantly less overhead.
MozReview-Commit-ID: LeIrUVh1yD4
This extracts the logic from the emitter that handles support files in ini
manifests to a seperate function in testing.py, so that this logic can be
re-used to determine how to install all the files necessary to run a particular
test fon the corresponding object in all-tests.json.
MozReview-Commit-ID: GSEhEGm09IL
DONTBUILD NPOTB
If the target triple is noisy, let's just accept -arm and -i386
instead of being strict. We can be more strict when things have
settled.
MozReview-Commit-ID: FDNJ3TuY51d
--HG--
extra : rebase_source : 3db70abe6818fbe0360406f20de899867232df02
extra : amend_source : d324c229b1713adb844407078d6cc4d00d84b56d
A few notes:
* This doesn't accommodate general OMNIJAR_NAME definitions. The
current name (assets/omni.ja) is baked into the product in a few
places, and is very unlikely to change, so we just error out if this
isn't true.
* This makes the package-manifest.in file authoritative for what goes
into assets/, libs/, and the APK root. Previously,
package-manifest.in wrote into assets/ and libs/ but
upload-files-APK.mk also had a convoluted DIST_FILES filtering
process to work through before a file actually made it into the APK.
* This is intentional about repackaging. It simplifies the repackage
step rather than trying to make unpackage-then-repackage the same as
just package. I pretty much never get repackaging correct the first
time; this should help. (I've manually tested it.)
* The ALREADY_SZIPPED during repackaging is subsumed by the previous
check if UNPACKAGE is set. The custom linker expects stored, not
deflated, libraries, so there's some small legwork to accommodate
that in mozjar.
MozReview-Commit-ID: JvVtIUSX685
--HG--
extra : rebase_source : fd8a9cfe3dc364d23b1065995db599f99e676e38
The initial goal of templates was to provide a way to write shorter
constructs for some generic tasks during configure. But the limitations
of the sandbox and the properties of templates made them used for more
general functions.
Consequently, this led to templates having to be available from
anywhere, which, in turn, led to difficult to introspect constructs.
With bug 1257823, we've made almost everything use set_config and
similar functions from the global scope, but we don't enforce that
those primitives are only used at the global scope.
This change does that: it enforces that primitives are only used at
the global scope. Or in templates.
Now, since templates were used for other purposes than generic uses
of other primitives, we now allow non-template functions to be declared.
Those can be used everywhere, but don't have access to the sandbox
primitives.
Currently, we have @advanced, that gives the decorated functions access
to all the builtins and consequently, to the import statement.
That is a quite broad approach and doesn't allow to easily introspect
what functions are importing which modules.
This change introduces a new decorator that allows to import modules one
by one into the decorated functions.
Note: by the end of the change series, @advanced will be gone.
So far, we've been using the lowercase of the variable name, but it's
not enough for some special cases. Those special cases could do their
own business, but then, they'd have to duplicate 90% of check_prog,
which is less desirable.
While DummyFunction is descriptive of what the instances are (and they
can't even be called), the various uses of isintance(obj, DummyFunction)
are kind of confusing, especially when they are in moz.configure land
(and this bug is about to add another one).
subprocess functions doesn't directly take file-like objects, so add a
minimalistic wrapper to do the right thing instead of subprocess.call
when given a file-like object.
And since the file is also used for old-configure, close our handle on
the file before spawning old-configure, and make old-configure append
there instead of truncating the file.
Mike Hommey
Mike Shal
Luca Greco
Wes Kocher
Matt Howell
Byron Campen [:bwc]
Gregory Szorc
Carsten "Tomcat" Book
Nathan Froyd
Chris Manchester
Chris Pearce
Andreas Farre
Sebastian Hengst
George Wright
Ryan VanderMeulen
Nick Alexander