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
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.
Mike Hommey