Thorium Building Discussion

[Alex313031]

@gz83 Alex313031/Thorium-Win-AVX2#9

[Alex313031]

@gz83 @midzer @pierro78 Just added these new icons. > https://github.com/Alex313031/Thorium/tree/main/logos/NEW/webui and > https://github.com/Alex313031/Thorium/tree/main/ui/webui/resources/images

[gz83]

@Alex313031 These new icons are great. In addition, will there be icons in other colors in the future?

[Alex313031]

@gz83 Possibly, it is just an experiment right now.

[Alex313031]

@gz83 Figured out why you were getting the "Cannot rebase-update with detached head + uncommitted changes." error. Fixed it in trunk.sh > de7c934

It was because of an untracked file that thorium uses that's not in the chromium tree.

[gz83]

@Alex313031 The rebase error has been fixed, which is a pleasant surprise, wait for the next compilation to test.

[Alex313031]

@gz83 I have made a little batch file called thor_compat_mode.bat in the misc folder here and in the root of the thorium-win and thorium-avx2 repos, as well as added it to the latest win and win avx2 releases, and a note on how to use it.
It automates setting the compatibility mode to make it easier for new users/new thorium installs.

[gz83]

Wow, that looks great. However, I still hope that Thorium can be opened normally, not in compatibility mode. @Alex313031

[Alex313031]

@gz83 Me too, the bug seems to come and go, and with no errors during compiling, and the browser working normally otherwise, its very hard to know if it's upstream, in thorium, or has to do with the compiler flags in thorium. If it's upstream, hopefully they'll fix it once and for all, if its in thorium, hopefully i can find where. If it has to do with the compiler flags however, I wont fix it, because as one of the goals of thorium is to have the highest performance of any chromium based browser, I would consider it a necessary evil to have the compat mode bug if it means keeping the the compiler flags. If it is just one flag, or only in a certain component, I might look into disabling certain things. But the main ones like AVX and the -O3 cflags I wont get rid of no matter what, because thats where the majority of thorium's speed comes from.

[gz83]

@gz83 Me too, the bug seems to come and go, and with no errors during compiling, and the browser working normally otherwise, its very hard to know if it's upstream, in thorium, or has to do with the compiler flags in thorium. If it's upstream, hopefully they'll fix it once and for all, if its in thorium, hopefully i can find where. If it has to do with the compiler flags however, I wont fix it, because as one of the goals of thorium is to have the highest performance of any chromium based browser, I would consider it a necessary evil to have the compat mode bug if it means keeping the the compiler flags. If it is just one flag, or only in a certain component, I might look into disabling certain things. But the main ones like AVX and the -O3 cflags I wont get rid of no matter what, because thats where the majority of thorium's speed comes from.

@Alex313031 There are also many reports on this issue on the Internet. According to the current situation, it is not easy to investigate. Personally, I think we can focus on those versions that can run normally, and focus on upstream modification, compilation process, compilation parameters and other things.

[Alex313031]

@gz83 Yeah, thats actually where I got the compatibility fix, is just by googling the error and seeing multiple examples of chromium, chrome, and other chromium based browsers having this issue. And more often than not the results were people complaining when they were on the beta/dev/canary/or equivalent. At least I made the .bat. That way someone can just download the mini installer and bat, and double click them one after the other to install on win.

[gz83]

@Alex313031 There is a problem with the trunk.sh file and needs to be repaired. The specific error is as follows.
rm: cannot remove '/root/chromium/src/ui/webui/resources/images/infra.png': No such file or directory

Added: Error when running trunk.sh for the first time.

[Alex313031]

As noted in the building instructions, the scripts and instructions and thorium tree all assume that thorium and chromium are in $HOME. I assume that since your on a server thats why your home is root's home. Make sure both are in $HOME. It could also be that since it's fresh, that file isn't there so in that case, I will add -f to that rm line in the script so that it doesn't check whether it exists or not.

EDIT: Ok its ready to go. Prepare for some nice minor UI changes.

[gz83]

@Alex313031
Now the compilation encounters a new error, the error is as follows.
../../v8/src/parsing/parser.h(271,57): error: use of undeclared identifier 'v8_file_logger_'
pending_error_handler(), runtime_call_stats_, v8_file_logger_,
^
Note: including file: ../../v8/src/parsing/preparse-data-impl.h

[Alex313031]

@gz83 OK fixed

[Alex313031]

@gz83 @midzer Also, Im working on a tentative fix for the compat mode bug. See > https://bugs.chromium.org/p/chromium/issues/detail?id=803591

Also, new VS artifacts zip will be uploaded soon based on latest VS 2022 and 10.0.20348.0 Win SDK + Debugging Tools. I will put the new .zip in the snippets, and update the build scripts and windows instructions files to reflect this. I will also package windbg for native debugging on a win machine if you dont want to install the whole thing on a target test machine if you are only building on linux.

[gz83]

@gz83 @midzer Also, Im working on a tentative fix for the compat mode bug. See > https://bugs.chromium.org/p/chromium/issues/detail?id=803591

Also, new VS artifacts zip will be uploaded soon based on latest VS 2022 and 10.0.20348.0 Win SDK + Debugging Tools. I will put the new .zip in the snippets, and update the build scripts and windows instructions files to reflect this. I will also package windbg for native debugging on a win machine if you dont want to install the whole thing on a target test machine if you are only building on linux.

@Alex313031 I'll keep following the above, and look forward to new files from you.

[gz83]

@gz83 @midzer Also, Im working on a tentative fix for the compat mode bug. See > https://bugs.chromium.org/p/chromium/issues/detail?id=803591

Also, new VS artifacts zip will be uploaded soon based on latest VS 2022 and 10.0.20348.0 Win SDK + Debugging Tools. I will put the new .zip in the snippets, and update the build scripts and windows instructions files to reflect this. I will also package windbg for native debugging on a win machine if you dont want to install the whole thing on a target test machine if you are only building on linux.

@Alex313031 Now there is a line of reference in the BUILD.gn file under the chrome folder that needs to be deleted. Can I modify the corresponding file in the Thorium repository? Or is it up to you to modify it?

EDIT:There is also a settings_strings.grdp and args.gn that also needs to be modified.

[Alex313031]

@gz83 Thanks for letting me know. I fixed all of them.

[Alex313031]

@gz83 @midzer Make sure you guys update your args.gn for all platforms.

[Alex313031]

@gz83 @midzer Attention Thorium Contributors: See the new DEBUG dir in infra. It has a readme, and *.gn files and scripts to make debug builds of Thorium for Linux/Windows, it also has a script to build the standalone Thorium UI Debug Shell. It also contains a new document describing the gn arguments, (me and @gz83 talked about this). >https://github.com/Alex313031/Thorium/blob/main/infra/DEBUG/ABOUT_GN_ARGS.md If you do nothing else, please at least read this file.

[gz83]

@Alex313031 OK, i got it

[Alex313031]

@midzer Here is readme and the files/scripts to make the .icns files for Mac.
https://github.com/Alex313031/Thorium/tree/main/logos/NEW/mac/gen#readme

[Alex313031]

@gz83 @yochananmarqos @midzer Attention Thorium contributors, the naming scheme for Thorium .deb, .zip, .appimage, and .exe and MacOS .dmgs is being changed and standardized, both in source code, and in what is expected when making release files or pkgbuild/.yml files for Arch and AppImages respectively.

For Linux, see these commits > fd7d55d 68d9a3d 59c8517 and 46b3566

I.E. a package should now be named like Thorium_Browser_105.0.5142.0_amd64.deb Thorium_Browser_105.0.5142.0_amd64.rpm
and Thorium_Browser_105.0.5142.0_amd64.AppImage.
The portable .zips should also be named the same way like Thorium_Browser_105.0.5142.0_amd64.zip. The arch should also be named accordingly in lower case like sse4 or arm64 if it is not x64.

For Windows, the installer should always be lower case, EXCEPT if it is an AVX2 version. I.E. a regular version should be named like
thorium_mini_installer.exe and the AVX2 version like thorium_AVX2_mini_installer.exe.

For the Windows portable .zips, it should show the version and be in uppercase like Thorium_105.0.5114.0.zip and Thorium_AVX2_105.0.5114.0.zip

For MacOS, the name should now include the version number, as well as the arch, like Thorium_MacOS_105.0.5114.0_ARM64.dmg and Thorium_MacOS_105.0.5114.0_X64.dmg.

This is being done to standardize the naming scheme across platforms, and so that contributors and users know exactly the version and architecture they have.

For example, I have had multiple files downloaded with the same name, and forgot which one was which. Users might encounter the same when trying different versions/architectures. This also makes it easier on me when I am doing releases on GitHub.

For some of these, you will have to manually rename the file. For example, Windows AVX2 releases, Mac releases, and portable .zips.
@midzer and @gz83, you should rename the file(s) before sending them to me via Wormhole, as I often have multiple Thorium releases in my downloads folder.
@midzer This will also mean you will need to update the Release and Packages(.gz) files in the debian repository. After a little while, we should also remove old .debs with the old naming scheme from the repo.
@yochananmarqos You should update your PKGBUILD to reflect this new naming scheme.
@Alex313031 I will be updating the READMEs, and I am uploading the latest linux release with the new scheme now.
Please comment or like so I know you have read and understood this change.

[gz83]

@Alex313031 ok, got it

[midzer]

Understood.

The debian package name is still thorium-browser-unstable though. So it might be worth it to open a discussion whether we build for a more stable tag in order to reduce general work load (for the rebaser and builder).

[Alex313031]

@midzer Yes, I forgot to add that one should change it to remove the unstable part.

[yochananmarqos]

You should update your PKGBUILD to reflect this new naming scheme.

Nothing has changed with the Debian package name nor folder structure. Not sure what you think I should change.

EDIT: Ah, seems the subject was already addressed.

[Alex313031]

@midzer @gz83 Attention Thorium contributers: I have created a seperate testing account for Thorium.

It is [email protected] and the password is ThoriumRocks1.

This account should be used for testing Sync, as well as making bugs or posting in the Chromium Dev Group. If I find a bug, I will probably use my personal account, and you guys can use your personal accounts too, but if you use this account, this way we can all access it in one central location and collaborate.

Fun facts: The first name is Thorium and the Last name is Browser. The birthday is September 8, 2008, Chromium's birthday, and the gender is "Machina" lolol

[gz83]

@Alex313031 ok got it

@midzer @gz83 Attention Thorium contributers: I have created a seperate testing account for Thorium.

It is [email protected] and the password is ThoriumRocks1.

This account should be used for testing Sync, as well as making bugs or posting in the Chromium Dev Group. If I find a bug, I will probably use my personal account, and you guys can use your personal accounts too, but if you use this account, this way we can all access it in one central location and collaborate.

Fun facts: The first name is Thorium and the Last name is Browser. The birthday is September 8, 2008, Chromium's birthday, and the gender is "Machina" lolol

[Alex313031]

@yochananmarqos @midzer @gz83 Attention Thorium contributors:
I have created a 10 question survey to view user satisfaction and how people are installing Thorium. It was created with surverymonkey, and I checked the boxes to anonymize your answers and to allow multiple responses. I would appreciate it if you guys would complete it (should only take ~2 minutes) It is here > https://www.surveymonkey.com/r/TJHX7R7

This same text box and link is also in the latest linux release, and will be added to the latest release for all platforms. (Also midzer could you upload the new .deb to dl.thorium.rocks?)

[gz83]

@yochananmarqos @midzer @gz83 Attention Thorium contributors: I have created a 10 question survey to view user satisfaction and how people are installing Thorium. It was created with surverymonkey, and I checked the boxes to anonymize your answers and to allow multiple responses. I would appreciate it if you guys would complete it (should only take ~2 minutes) It is here > https://www.surveymonkey.com/r/TJHX7R7

This same text box and link is also in the latest linux release, and will be added to the latest release for all platforms. (Also midzer could you upload the new .deb to dl.thorium.rocks?)

@Alex313031 I have completed this questionnaire

[Alex313031]

@midzer @gz83 Attention Thorium contributors, I am proposing a change to trunk.sh, that would automatically sync the thorium repo to the latest as well as the chromium repo. Do you guys think this a good idea. I think it would be good, except in certain cases where there is an error on my part or a regression, in which case you would have to manually revert the repo back the the previous revision. But for normal building, it should be fine, and if you do come across a problem, usually I can just fix it instead of you having to revert.

[midzer]

Hmm, I cannot git pull origin main to latest Thorium repo version without git stash first, because I have uncommited changes. So modifying trunk.sh probably won't work for me. I'm against this change. It should be clear in any case to always have latest Thorium repo version for building.

[gz83]

@midzer @gz83 Attention Thorium contributors, I am proposing a change to trunk.sh, that would automatically sync the thorium repo to the latest as well as the chromium repo. Do you guys think this a good idea. I think it would be good, except in certain cases where there is an error on my part or a regression, in which case you would have to manually revert the repo back the the previous revision. But for normal building, it should be fine, and if you do come across a problem, usually I can just fix it instead of you having to revert.

@Alex313031 I personally think it's fine as it is now, the trunk.sh script doesn't need to be changed for now. As good as it is now, I have reservations about this new proposal, there may be a better way.

[Alex313031]

@midzer @gz83 Ok thanks for feedback, I will leave as is.

[Alex313031]

@yochananmarqos @midzer @gz83 Attention Thorium contributors: There are new flags for the trunk.sh and setup.sh scripts.

For trunk.sh, use the --shallow flag to do a shallow gclient sync. This should be done after deleting your chromium tree and using fetch --nohooks --no-history chromium to re-download it. Since Thorium is always tip-o-tree, it doesn't make sense to download and store the full git history. Using the above command and then using trunk.sh --shallow thereafter, it will allow you to have a Chromium checkout that is only ~30GB in size, and the shallow flag will keep it up to date while only keeping the latest version + 1 previous version. This saves space and bandwidth.
See > 7b9cb3a

For setup.sh, use the --mac flag to copy cdm_registration from //infra to the proper place, needed to overcome a discrepancy in the Widevine patches (which work for Linux & Windows, but not MacOS & ChromiumOS). This will be used as a replacement for the setup_mac.sh script, following further testing and verification by Midzer. I have solved the thorium_shell issues with the main setup.sh, meaning only this file needs to be changed for MacOS, hence the new flag. This also means we can start building Thorium Shell for Mac, although it will need to be distributed as a .app file, and won't be included in the main installation package, like the other platforms do.
See > 07a8658

If you have questions or want to propose changes, you know what to do ;).

[gz83]

@yochananmarqos @midzer @gz83 Attention Thorium contributors: There are new flags for the trunk.sh and setup.sh scripts.

For trunk.sh, use the --shallow flag to do a shallow gclient sync. This should be done after deleting your chromium tree and using fetch --nohooks --no-history chromium to re-download it. Since Thorium is always tip-o-tree, it doesn't make sense to download and store the full git history. Using the above command and then using trunk.sh --shallow thereafter, it will allow you to have a Chromium checkout that is only ~30GB in size, and the shallow flag will keep it up to date while only keeping the latest version + 1 previous version. This saves space and bandwidth. See > 7b9cb3a

For setup.sh, use the --mac flag to copy cdm_registration from //infra to the proper place, needed to overcome a discrepancy in the Widevine patches (which work for Linux & Windows, but not MacOS & ChromiumOS). This will be used as a replacement for the setup_mac.sh script, following further testing and verification by Midzer. I have solved the thorium_shell issues with the main setup.sh, meaning only this file needs to be changed for MacOS, hence the new flag. This also means we can start building Thorium Shell for Mac, although it will need to be distributed as a .app file, and won't be included in the main installation package, like the other platforms do. See > 07a8658

If you have questions or want to propose changes, you know what to do ;).

@Alex313031 OK, I have been informed of the relevant situation, and will discuss further in the future.

[Alex313031]

@yochananmarqos @midzer @gz83 Attention Thorium contributers: Script updates!! (And other updates)

All the scripts have been updated with new colours.
clean.sh has been fixed.

The LLVM build.py was horribly out of date, I rebased it and added it to the thor_developer_bookmarks.html.
In addition, it now will show more verbose stats, as well as now building LLVM with -O3 across the board, and Polly as well as OpenMP.

The trunk.sh has been updated to show more info about what it's doing.

The build.sh, build_win.sh, and build_mac.sh scripts have been reorganized, and there is now a fun little Chromium ASCII art at the end!
In addition, the build_mac.sh script now includes building thorium_shell as a target, hidden behind a --build-shell flag.

Pak has had some serious re-working by me, (Took me many hours and I learned some C, thanks StackOverflow lol). It now has better info and help (now with colour too!), parses out of scope dirs correctly, is built with -O3 and -msse4 (to support non-avx systems), and has new flags -h, -v, and -c; to show help, version, and the chromium ascii art, respectively. Version bump from 2.0.0 > 2.0.2.

The Chromium Dash and the new, updated/fixed copy of GitHubStat (now called GitHubStat2) is now on the Thorium website > Here, and both of these are in the thor_developer_bookmarks.html. These are good for tracking release milestones as well as the schedule for different platforms, and githubstat2 will now be the place to track download counts for Thorium releases (or any other repo, including your own).

Lemme know what you guys think 😁

[gz83]

@yochananmarqos @midzer @gz83 Attention Thorium contributers: Script updates!! (And other updates)

All the scripts have been updated with new colours. clean.sh has been fixed.

The LLVM build.py was horribly out of date, I rebased it and added it to the thor_developer_bookmarks.html. In addition, it now will show more verbose stats, as well as now building LLVM with -O3 across the board, and Polly as well as OpenMP.

The trunk.sh has been updated to show more info about what it's doing.

The build.sh, build_win.sh, and build_mac.sh scripts have been reorganized, and there is now a fun little Chromium ASCII art at the end! In addition, the build_mac.sh script now includes building thorium_shell as a target, hidden behind a --build-shell flag.

Pak has had some serious re-working by me, (Took me many hours and I learned some C, thanks StackOverflow lol). It now has better info and help (now with colour too!), parses out of scope dirs correctly, is built with -O3 and -msse4 (to support non-avx systems), and has new flags -h, -v, and -c; to show help, version, and the chromium ascii art, respectively. Version bump from 2.0.0 > 2.0.2.

The Chromium Dash and the new, updated/fixed copy of GitHubStat (now called GitHubStat2) is now on the Thorium website > Here, and both of these are in the thor_developer_bookmarks.html. These are good for tracking release milestones as well as the schedule for different platforms, and githubstat2 will now be the place to track download counts for Thorium releases (or any other repo, including your own).

Lemme know what you guys think 😁

@Alex313031 Recent changes have made the whole Thorium project better and better, and some of the changes have also made my compilation and testing easier. Since I haven't used all the things mentioned above, I will share my views and areas for improvement with you in time when I use them.

[Alex313031]

@midzer @gz83 Attention Thorium contributors: Scripts have been updated again.

setup.sh now offers the --raspi flag, on top of the --mac flag, for raspberry pi and macos, respectively.

The build_polly.sh script in //infra now offers --pgo, --jobs/-j, --verbose/-v, and --version. Defaults are: pgo off, jobs=10, verbose off.

The setup, and build scripts now show new ascii art. Trunk still shows the chromium ascii art, but setup now shows either thorium, raspi logo, or apple logo, and all the build scripts now show thorium logo.

I will also be adding a BUILDING_WIN_CROSS.md document soon, to complement the linux and windows ones, once again modeled after the upstream chromium ones.

[gz83]

@midzer @gz83 Attention Thorium contributors: Scripts have been updated again.

setup.sh now offers the --raspi flag, on top of the --mac flag, for raspberry pi and macos, respectively.

The build_polly.sh script in //infra now offers --pgo, --jobs/-j, --verbose/-v, and --version. Defaults are: pgo off, jobs=10, verbose off.

The setup, and build scripts now show new ascii art. Trunk still shows the chromium ascii art, but setup now shows either thorium, raspi logo, or apple logo, and all the build scripts now show thorium logo.

I will also be adding a BUILDING_WIN_CROSS.md document soon, to complement the linux and windows ones, once again modeled after the upstream chromium ones.

@Alex313031 ok got it

[Alex313031]

@midzer @gz83 @tomByrer @yochananmarqos Attention Thorium contributors. I have added a new script reset_depot_tools.sh Here. Use this if you have issues and want to clobber depot_tools, or clobber your whole Chromium checkout.

Also, the "--shallow" flag appears to be broken in trunk.sh for now, and it seems to only work once, but subsequent uses of it will still download the whole repo. IDK. 🤦🏼

Also, there is finally a working HEVC/H.265 patch. > Here Let me know if you have issues building with it, or if HEVC still doesn't seem to work. You can test HEVC playback directly (link to a h.265 video file) on woolyss tester with this link.

Also, update your args.gn, as is_chancie_wancie_build = true is being disabled for now. However, after further testing and verification, I will add the HEVC patches to the "ChromeOS" subdir of //third_party/ffmpeg, and then we can go back to using the ChromeOS version of ffmpeg for linux. I also want to eventually get MacOS using the CrOS version of ffmpeg. Windows will never be able to use it, but that's okay because the Windows ffmpeg already includes some of the extra formats that the CrOS version enables.

Until now, it has been kind of a mystery what exactly the ChromeOS version has over the Chrome version, but after looking in the source while adding these patches, I can now share what exactly it does. Here is a comparison of all of them:

---

Chromium FFmpeg : MPEG4, OGG, WebM, WAV, FLAC, MP3, Opus, PCM, Vorbis, VP8, VP9, Theora (Open Source, except for MP3, but Chromium has a special license to be able to use it and include it in FOSS builds.)

Chrome FFmpeg : All of the above, + HLS, AAC, AV1, H.264, GIFV, H.265 (Hardware Only, Unencrypted only)

ChromeOS (CrOS) FFmpeg: All of the above, + AVI, MOV, AMR, H.263, MPEG-DASH, H.265 (Hardware Only, but can play encrypted i.e. Widevine media streams)

In addition, the Windows FFmpeg also supports AVI and MOV, and larger libvpx profiles.

In addition, the Mac FFmpeg also supports QuickTime and MOV

The patch will add software H.265 Decoding, and using the ChromeOS version will bring those additional formats as well as encrypted H.265 content to Linux and Mac.

[gz83]

@midzer @gz83 @tomByrer @yochananmarqos Attention Thorium contributors. I have added a new script reset_depot_tools.sh Here. Use this if you have issues and want to clobber depot_tools, or clobber your whole Chromium checkout.

Also, the "--shallow" flag appears to be broken in trunk.sh for now, and it seems to only work once, but subsequent uses of it will still download the whole repo. IDK. 🤦🏼

Also, there is finally a working HEVC/H.265 patch. > Here Let me know if you have issues building with it, or if HEVC still doesn't seem to work. You can test HEVC playback directly (link to a h.265 video file) on woolyss tester with this link.

@Alex313031 ok got it

[Alex313031]

Updated this post, you can read more now

[gz83]

Updated this post, you can read more now

@Alex313031 I have seen the new addition after the edit lol

[Alex313031]

@midzer @gz83 Attention Thorium contributors! Three things.

1. setup.sh now has two more flags: --avx2 and --sse3, for making AVX2 and SSE3 builds for Linux/Windows.

2. HEVC ffmpeg patch has been updated. For testing, one should manually comment out this line in args.gn (for any platform)
   enable_hevc_parser_and_hw_decoder = true
   Following further testing to make sure software HEVC decoding works on all platforms, I may remove this line from all args.gn files.

3. There is a new setup_polly.sh script in Thorium/other/Polly. As per the lines printed when running setup.sh, this script should be done AFTER trunk.sh + setup.sh + build_polly.sh. All this script will do is ask if you want --regular, --avx2, or --sse3, and copy the relevant Polly build files (so that you guys don't have to do it manually). This script was made because we are building with Polly for most releases for platforms besides Mac, Raspi, and WOA (Windows On ARM), so it makes sense to automate it.

[gz83]

@midzer @gz83 Attention Thorium contributors! Three things.

1. setup.sh now has two more flags: --avx2 and --sse3, for making AVX2 and SSE3 builds for Linux/Windows.
2. HEVC ffmpeg patch has been updated. For testing, one should manually comment out this line in args.gn (for any platform)
   enable_hevc_parser_and_hw_decoder = true
   Following further testing to make sure software HEVC decoding works on all platforms, I may remove this line from all args.gn files.
3. There is a new setup_polly.sh script in Thorium/other/Polly. As per the lines printed when running setup.sh, this script should be done AFTER trunk.sh + setup.sh + build_polly.sh. All this script will do is ask if you want --regular, --avx2, or --sse3, and copy the relevant Polly build files (so that you guys don't have to do it manually). This script was made because we are building with Polly for most releases for platforms besides Mac, Raspi, and WOA (Windows On ARM), so it makes sense to automate it.

@Alex313031 ok got it

[Alex313031]

@midzer @gz83 Attention Thorium contributers. Three things.

1. You should re-clone the Thorium repo, with --recursive --recurse-submodules, or git pull in the same way, to add thorium-libjxl as a submodule.
2. You should normally use VERSION.sh to checkout chromium to THOR_VER (also exported as an env variable for later use if you need it). If you manually check out a version, you should make sure to use the DEPS file in thorium-libjxl, or update it yourself if you are checking out a version of chromium newer or older than the current THOR_VER. The deps file keeps track of out of tree dependencies and submodule versions, including re-adding //third_party/libjxl
3. Because tip-o-tree depot_tools sometimes has issues with stable revisions of Chromium, and the fact that I make changes to some depot_tools files, I have decided to clone depot_tools. We should use my fork from now on. Two caveats to this:

• You MUST set the environment variable (like in your .bashrc, or windows advanced settings) export DEPOT_TOOLS_UPDATE=0, or DEPOT_TOOLS_UPDATE and 0 for Windows. Otherwise, with every gclient runhooks, it will just update depot tools to the latest one.
• I will be maintaining this fork. Every time a new THOR_VER is pushed, I will checkout depot_tools at the corresponding revision, make my changes (only three files), and push it to the repo. This way, we know that the depot_tools we are using is correct and tested with the thorium version we are building, and includes the small fixes like for vs_toolchain.py and autoninja.

[Alex313031]

@StarterX4 Can you please update the AUR repo based on this new folder. You can use meld or something to see the changes I made. Main thing is that going forward, thorium will be built to stable, so the deb and wrappers will be thorium-browser-stable instead of unstable. Another thing is that I added the thorium_shell.png logo to the pkgbuild, and updated the copyrights and maintaners header. > https://github.com/Alex313031/Thorium/tree/main/infra/Arch_Linux

[Alex313031]

@midzer @gz83 Attention Thorium Contributors:

Midzer discovered that the Mac PGO profiles are now split into regular (mac) and ARM (mac-arm) versions.
Gz83 discovered that V8 now supports its own PGO profile pipeline separate from the main chromium one. Using python3 v8/tools/builtins-pgo/download_profiles.py download will download profile data files into the //v8 dir.

As such, I have added the V8 PGO download script and bash aliases to the VERSION.sh script.

I have also added v8_enable_builtins_optimization = true to most (but not all) of the args.gn* files.

Please see commit > 59ad921 and update your notes/bashrc accordingly.

On a side note: Using the beta WinSDK breaks windows builds. Midzer also seems to have had issues on MacOS with the latest XCode, but we are seeing if maybe it is a Thorium source code issue.

[Alex313031]

@midzer @gz83 Attention Thorium Contributors:

Just some stuff to be aware of -

1. We are now building Thorium with CGO (LTO Code Gen Optimization). See https://reviews.llvm.org/D141970 for the commit in LLVM that introduces this and explains a little bit. See this line in the main BUILD.gn > https://github.com/Alex313031/thorium/blob/main/src/build/config/compiler/BUILD.gn#L942 It takes the same 0 - 3 options as cflags and the --lto-O flag. Of course I have it set to 3.
   
   However, CGO is not present in LLVM 16, so one must use LLVM 17. But using the stock Chromium one lacks polly, and using upstream 17 is unstable. In addition, following @RobRich999 advice, and doing my own performance tests comparing Rob's Chromium, Thorium, and Google Chrome, I decided that for general public releases, we should not use polly anymore.
   
   I will not remove any of the polly code, nor remove the commented lines in the args.gns. If you want to build with polly, note that you will have to comment out the CGO line, or build LLVM yourself using the build_clang.py script [needs updating TODO:].

---

2. Previously, to build the .deb files on linux, you had to use "chrome/installer/linux:stable_deb" which is stupid. Individual targets are specified this way, but commonly used targets are in the root //BUILD.gn and point to the actual targets, so that you don't have to use the long name (i.e. just content_shell instead of "content/shell:content_shell")
   I have no idea why they didn't put deb/snap/rpm packaging in the root build.gn just like Windows and MacOS (i.e. mini_installer, instead of "chrome/installer/windows:mini_installer"). However, they finally did this (after 12 years!). You can now build linux installers with just the stable_deb and stable_snap targets.

---

3. In relation to linux packaging. I am working on an .rpm of thorium and will test in a Fedora linux VM. I am also working on FlatPak support > https://github.com/Alex313031/thorium/tree/main/infra/Flatpak/com.alex313031.thorium but this is not expected to ship until M115 or M116, provided that I set up a dev account on Flathub. I might also set up an account on Snapcraft](https://snapcraft.io/). This way we can have Thorium on both Linux app stores.

---

4. I finally added env variable support for the location of the Chromium repo in the scripts. This is useful to me because sometimes the drive I have the repo on is not the one I am booted from. Also, sometimes when compiling ThoriumOS, the ChromiumOS repo and Chromium repo are on separate drives. The scripts still default to $HOME, but can be overridden on the command line before running any script by using export CR_DIR="/absolute/path/to/chromium/src"

As a side note, I would like @midzer to provide me with an HEVC + AC3 .mp4 file to put on thorium rocks, so that I can test each release to make sure it actually works and plays the video.

Can you guys plz respond so I know you read this?

[midzer]

Aye. Thanks for the detailed information. File is ready, too.

[gz83]

I have read this message

@Alex313031

[Alex313031]

@gz83 @midzer Attention Thorium Contributors:

See notice in thorium special > https://github.com/Alex313031/Thorium-Special/releases/tag/migrate

[gz83]

I have received this message
@Alex313031

[Alex313031]

@midzer @gz83 Attention Thorium Contributors:

1. There is a minor issue since M113, where sometimes gclient sync will not clone devtools. The fix is to simply run ./version.sh twice. On Windows, run gclient sync --with_branch_heads --with_tags -f -R -D two times.

2. There is now a proper 'thorium' target. build.sh has been updated to use it. It should also work on mac and windows. So you can now build the main executable by using autoninja -C out/thorium thorium instead of 'chrome'. Using the chrome target also works. The thorium target is just a simple target in the root BUILD.gn that pulls in the chrome target as a dependency.

3. As per the above notice in Thorium Special, for this release I will be starting work on making seperate repos for all the platforms. Thorium special will only be for SSE3 builds or other special builds like Westmere for me and midzer. I will also eventually update all the links spread throughout the repo's documentation and the website.

[gz83]

ok got it

[Alex313031]

@midzer @gz83 Attention Thorium Contributors:

After ./setup.sh, you should also run ./patch_ac3.sh before building. This patches FFMPEG to allow AC3/E-AC3 audio.

The reason this is separated out, is because Android and arm32/arm64 targets do not support AC3.

So, unless you are making an Android build or a MacOS ARM64 build (this means you @midzer lol), you should use this script after setup.sh.

[gz83]

ok got it

@Alex313031

[midzer]

Confirmed.

[Alex313031]

@gz83 @midzer Attention Thorium Contributors:

Due to an upstream bug in how search engine resource ID's are handled, since Thorium adds Ask.com as one of the default search engines, but Chromium does not, you must take the following actions after everything else, but before actually starting the compile.

• Prerequisites (I have also added these to the install-build-deps.py file for easy future bootstrapping):
  On Linux: sudo apt install pngcrush optipng
  On MacOS: brew install pngcrush && brew install optipng (or equivalent)

• Fix the search engine favicon cache:
  Run (from within //chromium/src) python3 tools/search_engine_choice/download_search_engine_icons.py. This will refresh the favicons that are pre-cached in the repo and later stored in chrome_100_percent.pak for use by Chromium.

Without doing this, compilation will fail with an error saying something like Undefined identifier "uAsk.com", IDR_ASK_COM_PNG
This happens because although Ask.com is in the list of existing search engines, since it is not included by default for any locales (unlike Thorium), when they run this script on their CI servers, it skips downloading the Ask.com favicon, and so it is absent from the Chromium repo as of M125.

This will need to be done for Linux, Windows (cross building), MacOS, and ThoriumOS.
I haven't tested ARM64 or native Windows compilation, but if need be, I might temporarily check the image cache directory into the Thorium repo, since the python script won't run on Windows. However, we usually only natively compile the ARM64 windows releases, so it is not a huge concern.

Please respond so I know you all read this. You know what to do if you have issues or questions 😄

Oh, and I'm unsure if the image cache state will persist between trunk.sh and/or version.sh invocations, so you might have to run this for each build produced.

[gz83]

OK

[midzer]

Confirmed.

[Alex313031]

@midzer @gz83 Attention Thorium Contributors:

1. I added a warning to the setup.sh script, that if you run it without any flags (i.e. for a regular AVX Linux build), you must run ./patch_ac3.sh. I think this is the culprit for HEVC on latest thorium not working. #798

2. Secondly, the scripts for building for Linux, Mac, and Windows (excluding Android and ChromiumOS), now use autoninja -C out/thorium thorium_all instead of individual build targets. The original line is above it and commented out, in case you only want to build an individual target, or we run into unexpected issues.

The thorium_all target is defined here in the top level BUILD.gn >

thorium/src/BUILD.gn

Line 95 in fb07b7f

group("thorium_all") {

The thorium target is simply an alias for the chrome target, + chrome_dll (Windows only), + chrome_sandbox (Linux & ChromiumOS only).

The thorium_all target is the same as the thorium target, but additionally tacks on all the other targets for a release build, depending on the platform. For example, the mini_installer if is_win == true. It even handles is_debug == true, by adding the thorium_ui_debug_shell target.

Please confirm you guys have read this, and if you have any issues (like missing build stuff) with the "thorium_all" target, let me know.

EDIT: The reason for the patch_ac3.sh thing, is that we don't want to run it on Android, or ARM/ARM64 platforms like Raspi or MacOS arm64. The setup.sh script only applies it if the commandline flag is valid. However, this means that it was not being run when the script was run without arguments. Until I find a way to tell bash "if there are no command line arguments at all, run this code block", it has to be run manually. TODO: This may be easier to do in Python, which me and @gz83 have discussed migrating some of the main scripts from bash to python, to allow better OS interoperability (particularly for Windows).

[gz83]

OK

[midzer]

Understood.

[Alex313031]

@midzer @gz83 Attention Thorium Contributors: 2 things

1. I solved a linker error in //v8/v8_context_snapshot on Linux, and @gz83 I think it will fix it for native Windows compilation as well. I told Midzer about it as well.

What it ended up being is a bug in LLVM that only showed up when these two conditions are true:

1. The SIMD level is set to SSE4 or higher in cflags or ldflags
2. The lto_opt_level variable which controls the value for the -Wl,--lto-O# linker flag is set to 3 (it takes 0, 1, 2, and 3 just like the normal -O# and -Wl,-O# flags, where # is the number)

Until this bug is fixed, the thinLTO optimization level will be set to 2 instead of 3, because 2 is still good (and the Chromium default for official builds), and it is better to lower the LTO opt level than to remove SIMD optimizations like AVX, etc.
It is unknown whether this will fix a bug on MacOS that we have at least tracked down to the same file (the main compiler BUILD.gn in //build/config/compiler/).

---

2. When building for Windows, the name of the mini installer is automatically chosen now depending on your args. For example using use_sse3 and target_cpu = "x86" will make it spit out thorium_WIN32_SSE3_mini_installer.exe. With the default win_args.gn it will output thorium_AVX_mini_installer.exe.
   This also means I removed the line in build_win.sh that renames it, so gz83 will have to remove that from his Python scripts, and it also means no more manual renaming of the installer, although the portable .zips will still need the version number added to them like normal.

Get your machines out, hot and ready, cause' it's about time to start making some public releases! LOL. I will let you all know when the final commit is made tonight. As usual, respond so I know you read this.

[gz83]

Received, these changes look good.