Issue #1837 - Remove unused build back-ends from the tree.

This leaves just use of recursive make to build applications.

6 files changed, 23 insertions, 193 deletions

diff --git a/build/docs/cppeclipse.rst b/build/docs/cppeclipse.rst
deleted file mode 100644
index 3596a2f9a6..0000000000
--- a/build/docs/cppeclipse.rst
+++ /dev/null
@@ -1,54 +0,0 @@
-.. _build_cppeclipse:
-
-=====================
-Cpp Eclipse Projects
-=====================
-
-For additional information on using Eclipse CDT see
-`the MDN page
-<https://developer.mozilla.org/en-US/docs/Eclipse_CDT>`_.
-
-The build system contains alpha support for generating C++ Eclipse
-project files to aid with development.
-
-Please report bugs to bugzilla and make them depend on bug 973770.
-
-To generate a C++ Eclipse project files, you'll need to have a fully
-built tree::
-
-   mach build
-
-Then, simply generate the Eclipse build backend::
-
-   mach build-backend -b CppEclipse
-
-If all goes well, the path to the generated workspace should be
-printed.
-
-To use the generated Eclipse project files, you'll need to
-have a Eclipse CDT 8.3 (We plan to follow the latest Eclipse release)
-`Eclipse CDT plugin
-<https://www.eclipse.org/cdt/>`_
-installed. You can then import all the projects into Eclipse using
-*File > Import ... > General > Existing Projects into Workspace*
--only- if you have not ran the background indexer.
-
-Updating Project Files
-======================
-
-As you pull and update the source tree, your C++ Eclipse files may
-fall out of sync with the build configuration. The tree should still
-build fine from within Eclipse, but source files may be missing and in
-rare circumstances Eclipse's index may not have the proper build
-configuration.
-
-To account for this, you'll want to periodically regenerate the
-Eclipse project files. You can do this by running ``mach build
-&& mach build-backend -b CppEclipse`` from the
-command line.
-
-Currently, regeneration rewrites the original project files. **If
-you've made any customizations to the projects, they will likely get
-overwritten.** We would like to improve this user experience in the
-future.
-
diff --git a/build/docs/index.rst b/build/docs/index.rst
index 75000aff33..fa1434b852 100644
--- a/build/docs/index.rst
+++ b/build/docs/index.rst
@@ -28,14 +28,6 @@ Important Concepts
    locales
    rust
 
-integrated development environment (IDE)
-========================================
-.. toctree::
-   :maxdepth: 1
-
-   cppeclipse
-   visualstudio
-
 mozbuild
 ========
 
diff --git a/build/docs/supported-configurations.rst b/build/docs/supported-configurations.rst
index cc2c1ea728..cfd1c98264 100644
--- a/build/docs/supported-configurations.rst
+++ b/build/docs/supported-configurations.rst
@@ -5,41 +5,44 @@ Supported Configurations
 ========================
 
 This page attempts to document supported build configurations.
+For more up-to-date information please go to http://developer.palemoon.org/
 
 Windows
 =======
 
-We support building on Windows XP and newer operating systems using
-Visual Studio 2010 and newer.
+We support building on Windows 7 and newer operating systems using
+Visual Studio 2015 U3.
 
-The following are not fully supported by Mozilla (but may work):
+The following are not fully supported (but may work):
 
-* Building without the latest *MozillaBuild* Windows development
-  environment
+* Building with a *MozillaBuild* Windows development
+  environment not mentioned on the developer documentation site.
 * Building with Mingw or any other non-Visual Studio toolchain.
 
 OS X
 ====
-
-We support building on OS X 10.6 and newer with the OS X 10.6 SDK.
+(This section needs updating)
+We support building on OS X 10.8 and newer with the OS X 10.8 SDK.
 
 The tree should build with the following OS X releases and SDK versions:
 
-* 10.6 Snow Leopard
-* 10.7 Lion
 * 10.8 Mountain Lion
 * 10.9 Mavericks
-
-The tree requires building with Clang 3.3 and newer. This corresponds to
-version of 4.2 of Apple's Clang that ships with Xcode. This corresponds
-to Xcode 4.6 and newer. Xcode 4.6 only runs on OS X 10.7.4 and newer.
-So, OS X 10.6 users will need to install a non-Apple toolchain. Running
-``mach bootstrap`` should install an appropriate toolchain from Homebrew
-or MacPorts automatically.
-
-The tree should build with GCC 4.4 and newer on OS X. However, this
+* 10.10 Yosemite
+* 10.11 El Capitan
+* 10.12 Sierra
+* 10.13 High Sierra
+* 10.14 Mojave
+* 10.15 Catalina
+* 11 Big Sur (Including Apple ARM SoC)
+
+The tree requires building with Apple's Clang 4.2 that ships with Xcode.
+This corresponds to Xcode 4.6 and newer. Xcode 4.6 only runs on OS X 10.7.4
+and newer.
+
+The tree should build with GCC 7.1 and newer on OS X. However, this
 build configuration isn't as widely used (and differs from what Mozilla
-uses to produce OS X builds), so it's recommended to stick with Clang.
+uses to produce OS X builds).
 
 Linux
 =====
@@ -47,9 +50,6 @@ Linux
 Linux 2.6 and later kernels are supported.
 
 Most distributions are supported as long as the proper package
-dependencies are in place. Running ``mach bootstrap`` should install
-packages for popular Linux distributions. ``configure`` will typically
+dependencies are in place. ``configure`` will typically
 detect missing dependencies and inform you how to disable features to
 work around unsatisfied dependencies.
-
-Clang 3.3 or GCC 4.4 is required to build the tree.
diff --git a/build/docs/visualstudio.rst b/build/docs/visualstudio.rst
deleted file mode 100644
index 3fbf28e94b..0000000000
--- a/build/docs/visualstudio.rst
+++ /dev/null
@@ -1,100 +0,0 @@
-.. _build_visualstudio:
-
-======================
-Visual Studio Projects
-======================
-
-The build system contains alpha support for generating Visual Studio
-project files to aid with development.
-
-To generate Visual Studio project files, you'll need to have a configured tree::
-
-   mach configure
-
-(If you have built recently, your tree is already configured.)
-
-Then, simply generate the Visual Studio build backend::
-
-   mach build-backend -b VisualStudio
-
-If all goes well, the path to the generated Solution (``.sln``) file should be
-printed. You should be able to open that solution with Visual Studio 2010 or
-newer.
-
-Currently, output is hard-coded to the Visual Studio 2010 format. If you open
-the solution in a newer Visual Studio release, you will be prompted to upgrade
-projects. Simply click through the wizard to do that.
-
-Structure of Solution
-=====================
-
-The Visual Studio solution consists of hundreds of projects spanning thousands
-of files. To help with organization, the solution is divided into the following
-trees/folders:
-
-Build Targets
-   This folder contains common build targets. The *full* project is used to
-   perform a full build. The *binaries* project is used to build just binaries.
-   The *visual-studio* project can be built to regenerate the Visual Studio
-   project files.
-
-   Performing the *clean* action on any of these targets will clean the
-   *entire* build output.
-
-Binaries
-   This folder contains common binaries that can be executed from within
-   Visual Studio. If you are building the Firefox desktop application,
-   the *firefox* project will launch firefox.exe. You probably want one of
-   these set to your startup project.
-
-Libraries
-   This folder contains entries for each static library that is produced as
-   part of the build. These roughly correspond to each directory in the tree
-   containing C/C++. e.g. code from ``dom/base`` will be contained in the
-   ``dom_base`` project.
-
-   These projects don't do anything when built. If you build a project here,
-   the *binaries* build target project is built.
-
-Updating Project Files
-======================
-
-As you pull and update the source tree, your Visual Studio files may fall out
-of sync with the build configuration. The tree should still build fine from
-within Visual Studio. But source files may be missing and IntelliSense may not
-have the proper build configuration.
-
-To account for this, you'll want to periodically regenerate the Visual Studio
-project files. You can do this within Visual Studio by building the
-``Build Targets :: visual-studio`` project or by running
-``mach build-backend -b VisualStudio`` from the command line.
-
-Currently, regeneration rewrites the original project files. **If you've made
-any customizations to the solution or projects, they will likely get
-overwritten.** We would like to improve this user experience in the
-future.
-
-Moving Project Files Around
-===========================
-
-The produced Visual Studio solution and project files should be portable.
-If you want to move them to a non-default directory, they should continue
-to work from wherever they are. If they don't, please file a bug.
-
-Invoking mach through Visual Studio
-===================================
-
-It's possible to build the tree via Visual Studio. There is some light magic
-involved here.
-
-Alongside the Visual Studio project files is a batch script named ``mach.bat``.
-This batch script sets the environment variables present in your *MozillaBuild*
-development environment at the time of Visual Studio project generation
-and invokes *mach* inside an msys shell with the arguments specified to the
-batch script. This script essentially allows you to invoke mach commands
-inside the MozillaBuild environment without having to load MozillaBuild.
-
-While projects currently only utilize the ``mach build`` command, the batch
-script does not limit it's use: any mach command can be invoked. Developers
-may abuse this fact to add custom projects and commands that invoke other
-mach commands.
diff --git a/build/mach_bootstrap.py b/build/mach_bootstrap.py
index 0443eedda2..22eaa3425a 100644
--- a/build/mach_bootstrap.py
+++ b/build/mach_bootstrap.py
@@ -100,7 +100,6 @@ MACH_MODULES = [
     'python/mach/mach/commands/settings.py',
     'python/compare-locales/mach_commands.py',
     'python/mozbuild/mozbuild/mach_commands.py',
-    'python/mozbuild/mozbuild/backend/mach_commands.py',
     'python/mozbuild/mozbuild/compilation/codecomplete.py',
     'python/mozbuild/mozbuild/frontend/mach_commands.py',
     'services/common/tests/mach_commands.py',
diff --git a/build/moz.build b/build/moz.build
index 27f681369d..6567dd944c 100644
--- a/build/moz.build
+++ b/build/moz.build
@@ -97,10 +97,3 @@ if CONFIG['MOZ_VALGRIND']:
         'valgrind/i386-redhat-linux-gnu.sup',
         'valgrind/x86_64-redhat-linux-gnu.sup',
     ]
-
-if CONFIG['MOZ_ARTIFACT_BUILDS']:
-    # Ensure a pre-built interfaces.xpt installed to the objdir by the artifact
-    # code is included by the top-level chrome.manifest.
-    EXTRA_COMPONENTS += [
-        'prebuilt-interfaces.manifest',
-    ]