Граф коммитов

8 Коммитов

Автор SHA1 Сообщение Дата
Tooru Fujisawa 5e98e8f08d Bug 1549954 - Link in-tree brotli library if BinAST is enabled. r=glandium
Differential Revision: https://phabricator.services.mozilla.com/D30476

--HG--
extra : moz-landing-system : lando
2019-05-21 20:35:25 +00:00
Andreea Pavel a4546667a5 Backed out 2 changesets (bug 1551473, bug 1549954) win 2012 SM bustages on a CLOSED TREE
Backed out changeset aac842bf7f7b (bug 1551473)
Backed out changeset 2a4a5afa1ff2 (bug 1549954)
2019-05-21 19:30:36 +03:00
Tooru Fujisawa 706c8c7b08 Bug 1549954 - Link in-tree brotli library if BinAST is enabled. r=glandium
Differential Revision: https://phabricator.services.mozilla.com/D30476

--HG--
extra : moz-landing-system : lando
2019-05-21 15:09:03 +00:00
Christian Holler 5e6434ac23 Bug 1431090 - Add FuzzingInterface support to JS engine. r=jandem
This patch adds basic support for the fuzzing interface in the JS engine on top
of the last patch. This includes all the necessary code except for actual
targets (just an example target skeleton) and also makes sure that the fuzzing
code is packaged for the standalone release.

MozReview-Commit-ID: D6Tyebz3jZS

--HG--
extra : rebase_source : f07a5d2bf8e09fb6c93501e58fbb958004e2fa05
2018-01-17 17:05:04 +01:00
Coroiu Cristina faa2f8c7da Backed out 2 changesets (bug 1431090) for Bf bustage at src/tools/fuzzing/interface/harness/FuzzerTestHarness.h
Backed out changeset 2e98bda3f397 (bug 1431090)
Backed out changeset eb6acc9e44ad (bug 1431090)

--HG--
rename : tools/fuzzing/registry/FuzzerRegistry.cpp => tools/fuzzing/libfuzzer/harness/LibFuzzerRegistry.cpp
rename : tools/fuzzing/registry/FuzzerRegistry.h => tools/fuzzing/libfuzzer/harness/LibFuzzerRegistry.h
rename : tools/fuzzing/interface/harness/FuzzerRunner.cpp => tools/fuzzing/libfuzzer/harness/LibFuzzerRunner.cpp
rename : tools/fuzzing/interface/harness/FuzzerRunner.h => tools/fuzzing/libfuzzer/harness/LibFuzzerRunner.h
rename : tools/fuzzing/interface/harness/FuzzerTestHarness.h => tools/fuzzing/libfuzzer/harness/LibFuzzerTestHarness.h
rename : tools/fuzzing/interface/harness/moz.build => tools/fuzzing/libfuzzer/harness/moz.build
2018-01-23 13:49:26 +02:00
Christian Holler 08e812cc03 Bug 1431090 - Add FuzzingInterface support to JS engine. r=froydnj
This patch adds basic support for the fuzzing interface in the JS engine on top
of the last patch. This includes all the necessary code except for actual
targets (just an example target skeleton) and also makes sure that the fuzzing
code is packaged for the standalone release.

MozReview-Commit-ID: D6Tyebz3jZS

--HG--
extra : rebase_source : 58e4d85e657347b061de0ed912365f2a955a86e3
2018-01-17 17:05:04 +01:00
Mike Hommey 38ff4b7d87 Bug 1426558 - Make autospider builds not rely on system libnspr. r=sfink
The only reason autospider builds succeed in running tests at the moment
is that there is a libnspr4 library installed at the system level on
Centos that is binary compatible with what the js shell requires.

While on the long run we should just avoid depending on libnspr4 at all,
in the short term, we should make the effort to make those tests use the
libnspr4 present in dist/bin.

For the tests executed from js/src/Makefile.in, it turns out there is
already a level of wrapping that does that, relying on run-mozilla.sh,
which is only installed on gecko builds. Installing it on standalone js
builds solve half the problem.

The other half is addressed by setting LD_LIBRARY_PATH before invoking
the js shell in the various places it's invoked.

--HG--
extra : rebase_source : 25f4b1f5c78eb84e48046dc83798f07eb02d4a81
2017-12-21 10:11:13 +09:00
Mike Hommey 3d67bc07a1 Bug 1417309 - Move some definitions from top-level moz.build to application-specific moz.build files. r=nalexander
When building with a --enable-project that is neither js nor a
toolkit-based one (like browser or mobile/android), we don't want to be
building things that are specific to gecko and/or spidermonkey.

At the same time, this lifts the exception that js standalone doesn't
have an app.mozbuild included, and makes the moz.build parsers that
don't set a MOZ_BUILD_APP get the same information as they were through
toolkit.mozbuild.

We still keep mfbt, build and a few other DIRS set from the top-level,
because at the moment, there aren't really any --enable-project that
would benefit from those not being recursed.
2017-11-16 08:37:32 +09:00