Building Epyrus: Prerequisites
Please refer to the Pale Moon Developer Documentation for the latest prerequisites and setting up a sane build environment initially, the correct Visual Studio or MozillaBuild version, needed packages on Linux, etc. As a UXP application, Epyrus will have more or less the same build requirements as Pale Moon, and this documentation will be kept up-to-date as the platform changes.
Aside from those listed in the Pale Moon documentation, there is one additional thing you may want if building Epyrus on Windows. The Outlook 2010 MAPI headers. They may or may not be included with the Windows SDK that you should have installed earlier. If you don't have them, just grab everything in this folder, and copy it to both:
C:\Program Files (x86)\Windows Kits\8.1\Include\shared
C:\Program Files (x86)\Windows Kits\10\Include\10.0.nnnnn.0\shared
Where nnnnn is whatever Windows SDK version the Pale Moon developer documentation told you to install. If it complains about files already existing, that means you already have them and should be fine. If all else fails, you can build without MAPI but have to explicitly disable it, which I will show you how to do below.
Getting the Source
The only supported method of getting Epyrus source code at this time is via git, and MozillaBuild unfortunately does not include it, meaning you will probably have to to install Git For Windows separately and alternate between MozillaBuild for building and Git Bash for source code management.
Once you have Git on your system and have entered the directory you wish to put the Epyrus source code into, run the following commands:
git clone https://repo.palemoon.org/athenian200/epyrus.git ./
git submodule init && git submodule update
It's also worth noting that if you want to build multiple UXP applications (such as Pale Moon and Epyrus), you will wind up with multiple separate copies of UXP as submodules of each application. While you may think this is wasteful, there is no simple, reliable, cross-platform way around this that isn't error-prone in my experience. Whatever shortcut you may have in mind to mess around with the file system so you only need one copy of UXP, don't try it, it's better to waste the disk space than to run into weird problems that you may spend hours trying to debug.
Build Instructions: Windows
You will need a .mozconfg file in the root of the folder you cloned the source into. I will provide an example of such a file below. I recommend opening the .mozconfig file in a plain text editor such as Vim or Notepad, and pasting the contents of my example into it.
# Tell the build system if we're building 64-bit. 64-bit builds are strongly recommended.
BUILD_64=1
ac_add_options --enable-calendar
# Uncomment this line if you need to build without MAPI headers
#ac_add_options --disable-mapi
# Processor architecture specific build options
if [ -n "$BUILD_64" ]; then
BUILD_ARCH=x64
ac_add_options --target=x86_64-pc-mingw32
ac_add_options --host=x86_64-pc-mingw32
else
BUILD_ARCH=x86
fi
# Automatically clobber if CLOBBER was touched
mk_add_options AUTOCLOBBER=1
# Application and target
ac_add_options --enable-application=mail
# Build options
# Adjust the -j parameter if you need more or fewer parallel build tasks
# Maximum supported without build errors is around 32
mk_add_options MOZ_MAKE_FLAGS="-j8"
ac_add_options --enable-optimize="-O2 -GTs -GS- -Qspectre -utf-8"
# It's preferred that you use the unofficial, generic Hermopolis
# branding if you have made significant changes to the application or the way it
# is built.
ac_add_options --enable-official-branding
export MOZILLA_OFFICIAL=1
# Only enable the internal updater if you supply automatic update infrastructure
# and have configured the relevant preferences in your branding!
ac_add_options --disable-updater
ac_add_options --enable-jemalloc
ac_add_options --enable-strip
ac_add_options --enable-security-sqlstore
ac_add_options --enable-devtools
ac_add_options --disable-parental-controls
ac_add_options --disable-accessibility
ac_add_options --disable-gamepad
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-webrtc
ac_add_options --enable-av1
WIN32_REDIST_DIR="C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Redist/MSVC/14.32.31326/$BUILD_ARCH/Microsoft.VC143.CRT"
WIN_UCRT_REDIST_DIR="C:/Program Files (x86)/Windows Kits/10/Redist/10.0.22621.0/ucrt/DLLs/$BUILD_ARCH"
If you installed Visual Studio to a different location than the default, you would need to specify the directory you used instead of the paths I gave above. But as long as you installed to the the default location, this should be correct.
Build Instructions: Linux
Essentially, building applications from source is a lot easier on most Linux distros than it is on Windows, especially open source forks of Mozilla that seem to be designed around a GNU environment rather than a normal Windows environment. No MAPI headers, no C Runtime DLLs to worry about redistributing. As a result, the .mozconfig you'll need for Linux is much simpler.
# Clear this if not a 64bit build
_BUILD_64=1
ac_add_options --enable-calendar
# Standard build options for Epyrus
ac_add_options --enable-application=mail
ac_add_options --enable-optimize="-O2 -w"
ac_add_options --enable-default-toolkit=cairo-gtk3
ac_add_options --enable-jemalloc
ac_add_options --enable-strip
ac_add_options --enable-security-sqlstore
ac_add_options --enable-devtools
ac_add_options --enable-av1
ac_add_options --disable-webrtc
ac_add_options --disable-gamepad
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-necko-wifi
ac_add_options --disable-updater
ac_add_options --with-pthreads
ac_add_options --enable-appcompat-guid
# It's preferred that you use the unofficial, generic Hermopolis
# branding if you have made significant changes to the application or the way it
# is built.
ac_add_options --enable-official-branding
export MOZILLA_OFFICIAL=1
# Processor architecture specific build options
if [ -n "$_BUILD_64" ]; then
ac_add_options --x-libraries=/usr/lib64
else
ac_add_options --x-libraries=/usr/lib
fi
export MOZ_PKG_SPECIAL=gtk3
Building and Packaging
After making sure you are in the right place to enter build commands, use this:
./mach build
To simply build the application. To test out whether your build works or not, you can try:
./mach run
If you're satisfied with the test run and want to package it up, you can use:
./mach package
And on Unix systems, this will put a compressed .tar.xz in the dist directory within your build directory (which by default should be obj-ARCH-OS or something like that). You should be able to use this command to check if your package is present:
ls obj*/dist
On Windows, you may want to consider other options, because ./mach package will give you a .7z file that you may not want to deal with. If you want an executable installer package, just use:
./mach installer
And if you don't want to deal with downloading 7-Zip or your AV software complaining about the installer, you can create a .zip file instead with:
./mach mozpackage
Which should create a simple .zip file instead of a .7z file, increasing convenience at the cost of file size. Now, you should be done. Enjoy your build of Epyrus!