Compiler depuis les sources
Vous n’avez jamais à nous croire sur parole sur ce qu’il y a à l’intérieur. Le build ouvert est conçu pour être recompilé par n’importe qui.
Cette page porte sur la recompilation du build ouvert — celui des GitHub Releases. Le build sous licence (Gratuit avec GitHub et Pro) contient des patchs qui ne sont pas publics et ne peut pas être recompilé à partir de ces sources.
Anatomie d’un build
Un build Clearcote, c’est Chromium upstream plus un ensemble de patchs transparent et ordonné :
- Récupérer ungoogled-chromium à la révision épinglée (Chromium 149).
- Élaguer les sources, puis appliquer les patchs d’ungoogled (dégooglisation).
- Appliquer les patchs Clearcote (contrôles d’identité au niveau du moteur).
- Ajouter le
config/args.gnpublic (Windows) ouconfig/args.linux.gn(Linux). gn gen out/Defaultpuisninja -C out/Default chrome.
# high-level outline — see docs/BUILDING.md for the exact, pinned steps
git clone https://github.com/clearcotelabs/clearcote-browser
cd clearcote-browser
# fetch upstream, apply the patches, configure, build (gn + ninja) and package
WORK=~/clearcote-build ./build.sh windows # or: ./build.sh linux
# the archive lands in $WORK/distLa voie recommandée est le conteneur de build épinglé décrit dans BUILDING.md, qui embarque toutes les versions épinglées de la toolchain. Prévoyez 16 Go de RAM ou plus (32 Go recommandés), environ 120 Go d’espace disque et plusieurs heures.
Cibles
Windows x64 est cross-compilé sous Linux avec clang-cl / lld-link ; Linux x64 est un build natif. Le côté Windows est réellement complexe (préparation du Windows SDK + de la CRT, shims de toolchain) : chaque étape et chaque piège sont donc documentés pour être reproductibles.
Guides de référence
- docs/BUILDING.md — guide complet de compilation depuis les sources.
- patches/README.md — ce que fait chaque patch commité ; docs/PATCHES.md est le manifeste de conception plus général.
- docs/RESEARCH-DOSSIER.md — notes détaillées sur la compilation croisée.
- config/args.gn — la configuration de build publique.
Comme les patchs et la configuration du build ouvert sont publics et épinglés, un build que vous produisez devrait se comporter comme l’artefact publié — et vous pouvez faire un diff des patchs par rapport à l’upstream d’origine pour voir chaque modification, une par une. Les builds ne sont pas encore identiques au bit près : comparez donc le comportement plutôt que les hashs.