This directory contains script and documentation for rebuilding CEF from
scratch.

The motivations for such rebuilds, against using Spotify's builds, are:
- Spotify's builds do not have the proprietary CODECs built-in (meaning there
  are gaping holes in media support for Dullahan when using their builds).
- Spotify's builds after v77 will *all* crash randomly when using CEF with
  jemalloc (and since the latter is used by the Cool VL Viewer Linux builds,
  using Spotify's builds became a no-no after v74, which is the last fully
  working CEF version available from them).

Sadly, building CEF is a total nightmare. Not only does it need hours of git
fetches (45' for CEF 138 with 1Gbps optic fiber link to Internet) and
compilation (51' for CEF 138 on a Ryzen 9950X), but its build system
requirements are extremely tight, meaning you cannot build it, even on the
"official" and genuine (non-patched) Linux distros it is supposed to build
from.
The only solution is to use the "sysroot" build system (which will sort of
clone the "official" patched build system onto your machine to build CEF).

Alas, only a couple of CEF versions (the current stable one and the development
one) are supported by this "sysroot" build system (automate-git.py, depot tools
& Co) and attempting to build older versions most often lead to a failure (the
provided script tries to do what is supposed to be done, but it is often not
sufficient and more manual fixes would need to be applied).

You will find here a script I wrote (mkcef64.sh) that may be used to rebuild
the current release version of CEF (and perhaps a few former versions, with
some luck).

To rebuild CEF, first edit the BRANCH and COMMIT_DATE variables in the script
to match the current release version of CEF that you will find on:
https://bitbucket.org/chromiumembedded/cef/wiki/BranchesAndBuilding#markdown-header-current-release-branches-supported
The BRANCH to choose is the second (oldest) one (the first is the development
branch). For the (approximative) COMMIT_DATE, follow the link to the branch
(e.g. https://bitbucket.org/chromiumembedded/cef/src/5060/?at=5060) and in the
git, search for the last commit date for this branch.

Then open a terminal and point its current directory to a partition with at
least 80GB (!) of free space, and execute the script. It will create a CEF/
sub-directory and build CEF inside it.
E.g.: ~/cvlv-dullahan/building-cef/mkcef64.sh

At some point (after everything got downloaded, committed, etc), the script
will patch files, one in Chromium so to fix a crash bug occurring when using
it together with jemalloc, another to prevent CEF from creating a spurious
"Downloads" sub-directory in the user's home directory, and a last one when
compiling CEF 103/104 to properly link when building for Linux but without
GTK2. See (1) for full details on these patches.

If everything goes well, you will end up with a minimal distribution tarball
in the CEF/ directory (try: find CEF/ -name "cef_binary_*_minimal.tar.bz2").
You may place this tarball inside the cvlv-dullahan/ directory and use the
linux-build script (2) in the latter to build your Dullahan version against
your freshly compiled CEF package.

Good luck (you will need some) !

Henri Beauchamp.

PS: with CEF 104+, your build host system Python3 installation will need the
"importlib-metadata" module installed, else the build will fail at step
"ACTION //third_party/blink/renderer/bindings:generate_bindings_all)...
This is strange since the build system should use its own vpython installation,
but it also apparently relies on the host system Python. If your distro does
not provide that Python module, you may install it via pip, e.g. with:
pip install importlib-metadata (or 'pip3' depending on your distro).
PPS: you will need 'gperf' installed on the build system (strange again, since
the CEF build scripts are supposed to import all the needed third party tools
in its virtual build environment...

-------------------------------------------------------------------------------
(1) Without the patch to Chromium, the compilation would start and almost
    immediately stop with an error about a missing __libc_malloc symbol in
    chromium_git/chromium/src/base/process/memory_linux.cc
    The first patch changes that file to read, around lines 137 (for CEF 85):
	#elif defined(LIBC_GLIBC) && !BUILDFLAG(USE_TCMALLOC)
	 *result = malloc(size);
	I.e. it replaces "__libc_malloc" with "malloc" and "__libc_free" with
	"free".

    To prevent the force-creation of a "Downloads" directory in the user
    directory (e.g. under Linux when the said user chose to point their
    XDG_DOWNLOAD_DIR to their home directory, or when the Downloads directory
    is not set to the default path under Windows), a second patch is applied.
    For CEF 85 (it changed from older versions) the patched file is
    chromium_git/cef/libcef/common/resource_util.cc (but the script should find
    the right file automatically).
    It replaces "if (DownloadPathIsDangerous(*result))" with "if (false)" so to
	skip the culprit code.

	Note: the above bugs and issues have been reported upstream by me but the
	main CEF developer refuses to fix them; he's a bit... well, let's say
	"stubborn" to stay polite. :-/
	The corresponding reports can be found here:
	https://bitbucket.org/chromiumembedded/cef/issues/3095/linux-cef-actually-chromium-crashes-when
	https://bitbucket.org/chromiumembedded/cef/issues/3094/cef-force-creates-a-donwloads-directory-in

	With CEF 103 and 104 (the culprit file vanished from CEF 105, which is
	therefore no more affected), builds done with the use_gtk2=false option
	fail to link, obviously due to bogus defines in the code. So my third patch
	is fixing this issue.

	I added yet another patch for CEF 105, because under Linux, and given we do
	not use GTK dialogs (to avoid making libcef.so dependent on a specific GTK
	library version), the PDF viewer print button makes CEF crash; the patch
	disables entirely the printing with the built-in PDF viewer (simply use the
	"Open in system browser" button/feature of the floater and print from that
	browser instead).


(2) Do make sure the CEF_VERSION variable in that script is edited to match
    the version of your CEF build, else your tarball won't be found and the
    script would instead attempt to download it from Spotify's website.
