Build flags

Two binaries from one set of sources can differ in size, in speed and in what they send home. The difference is a list of settings, and on this engine that list is written down and checked before the compiling starts.

Build flags are the settings chosen before a browser is compiled and they decide what the finished binary contains.

What a setting decides

A setting is read once, before compiling, and it chooses which code is built at all. The same sources give a development build or a shipping build depending on this list alone.

A shipping build rather than a development one
A development build is larger and slower and carries extra checks that change how a browser behaves under a page.
One binary rather than a crowd of libraries
Splitting a browser into separate libraries is convenient while writing it and wrong for anything handed to a person.
No debugging symbols
Symbols make a download far heavier and serve the person building rather than the person running.

Settings a page can feel

Media support is decided here, and the engine is built with the codec set a real Chrome carries.

A browser that calls itself Chrome and cannot play what Chrome plays is a mismatch a site finds in one line.

What is cut out before compiling

Reporting, the promotion service and the vendor keys are switched off in this list rather than turned off later in a menu.

One area stays compiled and unreachable on purpose, because the setting that removes it breaks the dependency graph before a single file is compiled. With the keys left empty it has nowhere to call.

The list travels as a file

The settings are written into a file the generator reads, not joined onto one long command line.

On a single line the first note in the list would close everything after it, and the generator would quietly fall back to its own defaults for the rest.

The build checks that the list was taken

After generation the build reads back the file the generator left beside the output and counts the settings that are alive in it.

Too few of them, or a missing shipping line, and the build stops there rather than spending a night on the wrong binary.

1
The list is compared before regenerating
An unchanged list with a build graph already in place skips a generation step that costs many minutes.
2
The shipping lines are named explicitly
Two settings decide development against shipping, and both are looked for by name in the file.
3
The count is printed as a fact
When the step was skipped the build says so instead of claiming the generator accepted anything this time.

One list for every system

An antidetect browser is bought for sameness, so a profile has to behave the same whichever system its engine was built on.

The Linux build cuts its list out of the macOS build rather than keeping a copy, and the Windows list is compared against it setting by setting.

What this does not do

They do not decide what a site reads about your device. That comes from the patch set inside the engine and from the profile seed, not from how the sources were compiled.
They do not delete the code they switch off. Some of it stays compiled and unreachable, because the setting that removes it outright stops the build before it begins.
They do not travel with the binary. A build made elsewhere from another list is another browser, whatever name it wears.
They do not choose the version a browser reports. That is pinned with the sources and has to agree with the milestone a profile claims.

Check it

Each line above is a file you can open and a stand that keeps it honest.

The settings a macOS build uses and the file they are written to: engine/scripts/build-mac.sh
The Windows list held beside it: engine/scripts/build-win.sh
The Linux build cuts its list out of the macOS one: engine/scripts/build-linux.sh
Systems are compared so the lists cannot drift apart: apps/desktop/test/сборочные-скрипты.js

Questions

Are these the same as the flags on the command line?: No. A launch switch changes how a finished browser starts, and you can read it in the process list. A build setting decided what was compiled in the first place.
Does a shipping build make a browser harder to detect?: Not on its own. It removes the development behaviour that would stand out, and everything a page actually reads comes from elsewhere.
Why keep code that is switched off?: Because the setting that removes it stops the generator on the dependency graph. Switching the area off and leaving the vendor keys empty gives the same silence on the network.
Can I see the list a build used?: The settings a generator accepted are left in a file next to the build output, and the build prints how many of them it took.
Do the systems really build the same browser?: The lists are compared, and a setting that differs between systems is treated as a failure rather than a detail. The packaging around the engine differs, what a page reads does not.

Next to this

Run the build these settings produced

Install ARMANOS, open a profile and read the start page before you visit anything else.

Download ARMANOS Our browser engine