Add build script for easier building/debugging.

[wchen342]

Because of how hard it is to fetch and build chromium and there seems to be a lot of people who want to build ungoogled-chromium themselves but weren't able to, I strongly feel it is necessary to write a script that runs high-level commands and strips away all the complicated details in building chromium so that new users can start building chromium without getting lost in complicated chromium-specific building systems and terms.

Since the goal is as easy to use as possible, I limit the amount of configurable options on purpose and make things as standard as possible. The script is currently only tested for Linux builds but I will add Android and Windows soon. For Linux, it builds portable with the sysroot coming with source. The choice is made so that the differences between different distributions are minimized, as well as based on the fact that the benefits of ungoogled-chromium mainly comes from its flags, patches and domain substitutions, so using sysroot is an acceptable compromise IMO.

There are some extra functionalities underway, like a filter for patches and pruning lists, as well as downloading source tarball directly instead of checking out chromium source which is incredibly slow on a not very fast internet connections.

If you have any suggestions on how it can be improved or what additional functionality it should have, please let me know. If you think this is a good idea to have this script, I can ask @Eloston to move it under ungoogled-software so it is easier to edit for the rest.

[networkException]

LGTM 👍

I was a bit concerned about possible duplication with ungoogled-software/ungoogled-chromium-* repositories but I think with the extra functionalities you already mentioned this tool will basically only be used to build custom binaries for specific needs or for general development.

This might actually be a perfect opportunity to integrate https://github.com/ungoogled-software/contrib, not only for additional patches but also as a place to store custom domain substitution lists and so on.

Moving the repo to ungoogled-software would be very good as well.

[wchen342]

I was a bit concerned about possible duplication with ungoogled-software/ungoogled-chromium-*

I have thought about this and one of the problem of various platform repos is that it is very fragmented: Arch, Fedora, Gentoo and Debian/Ubuntu all have their own building systems, and not all of them are very friendly, especially when someone want to make modifications/develop on chromium source. E.g. Fedora (also OpenSUSE)'s rpm-based building system cannot start from the middle, which eliminates the benefit of ninja's incremental build. The script is written with development in mind so that modifications can be tested quickly.
Also there are a bunch of popular distros not covered by platform repos like OpenSUSE and Manjaro, they can benefit from a portable build too. The -portable repo seems to be based on Debian mainly and has problems very often and not working.

[mid-kid]

Dropping my 2ct, since I've been using the -portablelinux scripts for ages, on different distros including slackware and gentoo.
There's really nothing debian-specific about those scripts, it merely uses a debian image to generate an appimage if you so choose, but the base scripts are very minimal (really, it's just a copy-paste of the docs/building.md) and run anywhere chromium builds. It's just rather slow with getting updates at times, and it forces building using clang+lld.

[wchen342]

I mentioned -portable only because it was brought up and currently the scripts only has linux and android building ability, but building portablelinux is really not the goal of this scripts. Specifically,

• This script is meant to be cross-platform, thus not using bash but python. Not linux only, but for Android and Windows (which has been a huge problem recently) too. @Nifury maybe you can give some help here? Unfortunately I cannot add Mac support because I don't have Apple devices, but it can be added later by someone who have an Apple device.
• This script is development-oriented too. It can run any stage separately, like (re)applying the patches and pruning, without (re)downloading the chromium sources. Also it clone the chromium source tree by default instead of using the tarball, which has git ability and commit history coming with it.
• This script can cross-compile from, e.g. x64 to arm64.

[PF4Public]

@wchen342 You did a tremendous work!

Why did you do it as a submodule? Your script is a rather independent entity. It deserves its own repository under ungoogled-software organization, or inclusion into utils directory as a part of ungoogled-chromium itself. Given the detachment of your script from ungoogled patches [as a whole], I'm leaning more to a separate repository. In any case, your quick-build instructions (using your script) should be present here without any doubt, but don't forget to document your script in its own readme.

Your script might serve as a common ground for debugging issues, when hunting ungoogled-chromium bugs! Or otherwise proving them unrelated to ungoogled-chromium patches!

Cannot agree more that having such script for Windows could improve situation there immensely.

[Nifury]

@wchen342 Sure, I'll see what I can do.

[Nifury]

I just went over the code, and it seems there is not much code I can reuse. I would have to create big if blocks as building on Windows is quite different from building on Linux. Does that sound okay to you, or would it be better if I just refactor the existing Windows build script to provide similar functionalities?

[wchen342]

@Nifury Is it the build function? If so then it is OK to be a separate if block or even a separate function, since I don't expect builing to be the same. I know windows also has extra dependencies like Visual Studio stuff so you can add a block for those too.

[Eloston]

Dropping a note here that I will get back to this with more comments. I'd like to have a discussion so I can better understand the use-case and design, since I've also wanted to rework the entire build system to be closer to vanilla Chromium's. I'm also eager to hear what the other devs here have to say about this.

[wchen342]

Adding a note here too that I am also preparing an experimental daily docker build by Github Actions to pull chromium source of the corresponding stable version from Omaha, do the sync in the docker image, and then push the image to Docker Hub. So later if someone can skip the init and sync steps and instead do sth like:

docker pull ungoogled-chromium-src:latest

It will solve three problems at least:

• Greatly decrease the effort of downloading/syncing source
• Help decreasing the wasted time (at least I have) when building with OBS/Actions that for each different flavor I need to sync sources repeatedly
• Resolve the kind of dependency problems when not building on Debian/Ubuntu (see 4k60fps Video horrible performance after update #1701 (comment)).

[PF4Public]

I need to sync sources repeatedly

Why wouldn't you use source tarball, provided by google?

[wchen342]

@PF4Public Android needs different files so that doesn't work. Windows probably needs different files too.

[tangalbert919]

This is a good idea. It's just not clear to me if the objective of this build script is to negate the need to clone repos for specific systems (e.g. ungoogled-chromium-windows for Windows) and simply do all the building and debugging from this repository alone.

[wchen342]

The main goal is to simplify the building process so that we don't need to manually do all the git clone, gclient sync and other stuff like setting up environment variables, etc. It currently hard-codes repository links to platform-specific ones but an option can easily be added.
The builds are always portable because it doesn't use anything system-specific (except the VS toolchain on Windows). This can be a complement to those platform-specific repositories where each system has their own way of packaging.

do all the building and debugging from this repository

Do you mean like merging all the platform repositories back into this main repo? I think that is a different problem. There has always been a trade-off between large mono repos and smaller, separate repos. This was discussed before my time here and I think the conclusion was to separate them so it became what we see today.