Nothing uses this variable. blame suggests that it was used for HP-UX
once upon a time. The companion variable, MOZ_POST_PROGRAM_COMMAND, is
only used by HP-UX, but as we're not wholesale removing HP-UX
support (yet), we should leave MOZ_POST_PROGRAM_COMMAND alone.
changeset: 319212:a11309a6feb4
bookmark: bug-1245836-disable-compile-env
tag: tip
user: Axel Hecht <axel@pike.org>
summary: bug 1245836, nsinstall.py is in MOZILLA_DIR, r?glandium
Opt-in by adding --enable-gradle-mobile-android-builds.
Gradle dependencies (including the Android-Gradle plugin) are assumed
to be present. Local developers will fetch them from the jcentral
repository.
Android-specific Maven dependencies are shipped as "extras" with the
Android SDK, and should be found automatically by the Android-Gradle
plugin.
MozReview-Commit-ID: 966XgddWgEu
Enable building with Gradle using --with-gradle. Configure the
location of Gradle with --with-gradle=/path/to/gradle. For local
developers, this is always the in tree Gradle wrapper, which downloads
and installs the correct Gradle version automatically. In automation,
this will be a version of Gradle fetched from tooltool.
Configure the location to use to download Gradle Maven dependencies
(including the Android-Gradle plugin) by setting
GRADLE_MAVEN_REPOSITORY in your mozconfig. For local developers, this
defaults to the jcenter repository. In automation, this will be an
archived directory fetched from tooltool.
Android-specific Maven dependencies are shipped as "extras" with the
Android SDK, and should be found automatically by the Android-Gradle
plugin.
MozReview-Commit-ID: Hrkn88Vig5H
The behavior is not entirely idempotent (most notably for
buildconfig.html), but this can be improved later if necessary.
It is idempotent where it matters.
This allows to get rid of config/makefiles/rcs.mk and its uses.
On a CLOSED TREE because this is Android only.
When we switched to fine-grained Google Play Services bundling (Bug
1115004), we stopped shipping com.google.android.gms.analytics. That
silently breaks Adjust, which queries the Google Ad ID using
reflection: now the package isn't present! This patch restores the
Play Services libraries that Adjust relies on. (Sadly, this bloats
our APK tremendously.)
There is some hijinkery, however: the Play Services libraries
reference a library (org.apache.http) that is deprecated in Android
23! However, the library is still present on Android 23 devices,
which buys Google time to replace the offending code. This compiles
just fine, breaks the Proguard global optimization pass. To give
Proguard the information, we add the library as a Proguard "library
JAR". This is equivalent to the Google-provided Gradle `useLibrary`
directive.
msys-perl-wrapper was used to transform windows paths after the -I flag,
which was a preprocessor flag, which a) doesn't exist anymore and b) the
preprocessor has not even be in perl for years.
This commit produces an "install bouncer" APK which is a "hollow
shell" that looks like the main Fennec APK. In particular, both APKs have:
* the same Android package name (application id); and
* the same set of <permission>, <uses-permission>, and <uses-feature>
blocks in their manifests.
The bouncer APK must always have an android:versionCode smaller than
the main Fennec APK; for now, we will just bump that manually
mobile/android/bouncer/moz.build.
This commit produces an "install bouncer" APK which is a "hollow
shell" that looks like the main Fennec APK. In particular, both APKs have:
* the same Android package name (application id); and
* the same set of <permission>, <uses-permission>, and <uses-feature>
blocks in their manifests.
The bouncer APK must always have an android:versionCode smaller than
the main Fennec APK; for now, we will just bump that manually
mobile/android/bouncer/moz.build.
This simply packs the assets/ subdirectory of the distribution
directory into the assets/ directory of the Android APK using existing
mechanisms. It also removes the older method of manually pushing
files into dist/bin/distribution, from where they would be packaged
into the APK under distribution/.
The flag is used to create .sbr files, which bscmake subsequently uses to
create .bsc files. These files and related tools are, aiui, the ancestors
of Intellisense.
The -FR C*FLAGS are added to the build if MOZ_BROWSE_INFO or MOZ_BSCFILE
are set in the recursive make backend. While the former has an AC_SUBST,
the latter does not, so in practice, only the former can be set by
supported methods, and would need to be set in a mozconfig. At that
rate, people who do want those flags can add them in the C*FLAGS on
their own.
Developers are probably better served by the VisualStudio backend
anyways.
rustc, unlike our typical C++ compilers, can target multiple platforms
with ease through its use of the --target flag. To support
cross-compiling, we just need to pass the appropriate --target option.
rustc uses specific names for its accepted --target option, however, and
they are slightly different from the values we get out of autoconf. So
in addition to checking whether rustc can accept --target for our chosen
platform, we also need to munge autoconf's idea of the target into
something rustc understands.
We don't really care to set those in js/src/configure because the JS
engine doesn't use ObjC. We also don't care to preserve the += behavior
because there were no AC_SUBST in the first place, so it's unlikely
anyone has an override in their mozconfig and expects it to work.
Because of how subshells and exporting variables works with msys bash,
we need to explicitly re-export everything interesting for things
executed downstream from configure.
In https://llvm.org/bugs/show_bug.cgi?id=26090, we changed the default
behavior of clang-cl to accept unknown command line arguments. This
patch removes the Firefox workaround for this issue.
When adding a backend, we currently have to add them in three different
places so that they appear in the right places.
Instead, keep the list in a single place.
This is a partial revert of bug 1214462 part2. We don't need FFmpeg support on Android or Windows anymore; instead the functionality is provided by the FFVPX PDM.
Remove support for FFmpeg on Windows.
Several JS engine header files, notable RootingAPI.h, do:
class JS_PUBLIC_API(...) { ... };
which sticks __declspec(dllimport) on the type. clang-cl warns us that
it doesn't implement that, but since we're compiling with clang-cl as an
interesting side project, rather than shipping releases with it, we can
ignore that warning.