Typografiske konvensjoner
For å gjøre ting enkelt å følge, brukes en rekke konvensjoner gjennom hele boka. Her er noen eksempler:
./configure --prefix=/usr
Denne formen for tekst skal skrives nøyaktig som vist med mindre ellers notert i den omkringliggende teksten. Det brukes også til å identifisere referanser til spesifikke kommandoer.
install-info: unknown option
`--dir-file=/mnt/lfs/usr/info/dir'Denne formen for tekst (font med fast bredde) viser skjermens utdata, sannsynligvis resultatet av å gi en kommando. Det er også brukt til å vis filnavn som f.eks
/boot/grub/grub.conf
![[Notat]](../images/note.png)
Notat
Vennligst konfigurer nettleseren din til å vise tekst med fast
bredde en god monospace font, som du kan skille glyphene til
Il1 eller O0 helt klart.
Uthevet
Denne formen for tekst brukes til flere formål, men hovedsakelig for å understreke viktige poenger, eller for å gi eksempler på hva du skal skrive.
https://www.linuxfromscratch.org/
Denne formen for tekst brukes for hypertekstlenker eksternt til boken, for eksempel veiledninger, nedlastingssteder, nettsteder osv.
Denne tekstformen brukes for lenker internt til boken, for eksempel en annen del som beskriver en annen pakke.
cat > $LFS/etc/group << "EOF"
root:x:0:
bin:x:1:
......
EOF
Denne stilen brukes hovedsakelig når du oppretter konfigurasjonsfiler. Den første kommandoen (i fet skrift) forteller systemet om å opprette filen
$LFS/etc/groupfra det som er skrevet på følgende linjer, inntil sekvensen EOF påtreffes. Derfor skrives vanligvis hele denne delen nøyaktig som vist. Husk at kopier og lim er din venn!
<REPLACED TEXT>
Denne formen for tekst brukes til å kapsle inn tekst som burde være endret, og skal ikke skrives inn som vist, eller kopieres og limes inn. Vinkelparentesene er ikke en del av den bokstavelige teksten; de er en del av substitusjon.
root
Denne formen for tekst brukes til å vise en spesifikk systembruker eller gruppe referanse i instruksjonene.
Konvensjoner som Brukes for Pakkeavhengigheter
Når nye pakker opprettes, er programvarens forfattere avhengig av tidligere arbeid. For å bygge en pakke i BLFS, må disse avhengighetene bygges før ønsket pakke kan kompileres. For hver pakke er forutsetninger oppført i en eller flere separate seksjoner: Påkrevd, Anbefalt, og Valgfri.
Påkrevde Avhengigheter
Disse avhengighetene er det minste nødvendig for å bygge pakken. Pakker i LFS, og de nødvendige avhengigheter av disse nødvendige pakkene, er utelatt fra denne listen. Husk alltid å se etter nestede avhengigheter. Hvis en avhengighet sies å være «kjøretid,» da er den ikke nødvendig for å bygge pakken, men bare for å bruke den etter installasjon.
Anbefalte Avhengigheter
Dette er avhengigheter BLFS-redaktørene har bestemt er viktige for å gi pakken rimelige muligheter. Hvis en anbefalt avhengighet sies ikke å være «kjøretid,» pakke installasjonsinstruksjonene forutsetter at den er installert. Hvis den ikke er installert, kan instruksjonene kreve endringer, for å imøtekomme den manglende pakken. En anbefalt «kjøretid» avhengighet trenger ikke å være installert før du bygger pakken, men må bygges i etterkant for å kjøre pakken med rimelig evner.
Valgfrie Avhengigheter
Dette er avhengigheter pakken kan bruke. Integrering av valgfrie avhengigheter kan være automatiske av pakken, eller ytterligere trinn som ikke presenteres av BLFS kan være nødvendig. Valgfrie avhengigheter er noen ganger oppført uten eksplisitte BLFS- nstruksjoner. I dette tilfellet må du bestemme hvordan du skal utføre installasjonen selv.
Konvensjoner som Brukes for Kjernekonfigurasjonsalternativer
Noen pakker krever spesifikke kjernekonfigurasjonsalternativer. Den generelle layouten for disse ser slik ut:
Master section ---> Subsection ---> [*] Required parameter [REQU_PAR] <*> Required parameter (not as module) [REQU_PAR_NMOD] <*/M> Required parameter (could be a module) [REQU_PAR_MOD] <M> Required parameter (as a module) [REQU_PAR_MOD_ONLY] < /*/M> Optional parameter [OPT_PAR] < /M> Optional parameter (as a module if enabled) [OPT_PAR_MOD_ONLY] [ ] Incompatible parameter [INCOMP_PAR] < > Incompatible parameter (even as module) [INCOMP_PAR_MOD]
[...] til høyre gir navnet på alternativet, slik at du kan enkelt
sjekke om det er satt i din .config
fil. Merk at .config filen inneholder
et CONFIG_ prefiks foran alle
symbolske navn. Betydningen av de ulike oppføringene er:
Master section menyelement på øverste nivå Subsection undermenyelement Required parameter alternativet kan enten være innebygd eller ikke valgt: det må være valgt Required parameter (not as module) alternativet kan være innebygd, en modul eller ikke valgt (tri-state): den må velges som innebygd Required parameter (could be a module) alternativet kan være innebygd, en modul eller ikke valgt: den må velges, enten som innebygd eller som modul Required parameter (as a module) alternativet kan være innebygd, en modul eller ikke valgt: den må velges som en modul; velge den som innebygd kan forårsake uønskede effekter Optional parameter alternativet kan være innebygd, en modul eller ikke valgt: den kan velges som en modul eller innebygd hvis du trenger det for å drive maskinvaren eller valgfrie kjernefunksjoner Optional parameter (as a module if enabled) alternativet kan være innebygd, en modul eller ikke valgt: det kan velges som en modul hvis du trenger det for å drive maskinvaren eller valgfrie kjernefunksjoner, men å velge den som innebygd kan forårsake uønskede effekter Incompatible parameter alternativet kan enten være innebygd eller ikke valgt: det må ikke bli valgt Incompatible parameter (even as module) alternativet kan være innebygd, en modul eller ikke valgt: det må ikke bli valgt
Merk at, avhengig av andre valg, vinkelparentesene (<>) i konfigurasjonsmenyen kan vises som klammeparenteser ({}) hvis alternativet ikke kan fjernes, eller til og med som bindestreker (-*- or -M-), når valget er pålagt. Hjelpeteksten som beskriver alternativet spesifiserer de andre valgene som dette alternativet avhenger av, og hvordan de andre valgene er satt.
Bokstaven i blå er hurtigtasten for dette alternativet. Hvis du kjører make menuconfig, kan du trykke på en tast for å raskt gå gjennom alle alternativene med denne tasten som hurtigtast på skjermen.
SBU verdier i BLFS
Som i LFS, har hver pakke i BLFS en byggetid oppført i Standard Bygge enheter (SBUs). Disse tidene er i forhold til tiden det tok å bygge binutils i LFS, og er ment å gi litt innsikt i hvor lang tid det vil ta å bygge en pakke. De fleste tidene som er oppført er for en enkelt prosessor eller kjerne for å bygge pakken. I noen tilfeller store, langvarige bygg testet på flerkjernesystemer har SBU tider oppført med kommentarer som f.eks som '(parallelisme=4)'. Disse verdiene indikerer at testing ble utført ved hjelp av flere kjerner. Vær oppmerksom på at mens dette øker hastigheten på byggimng på systemer med den riktige maskinvaren, er speedupen ikke lineær og til en viss grad avhenger av den individuelle pakken og den spesifikke maskinvaren som brukes.
For pakker som bruker ninja (dvs. alt som bruker meson) eller rust, som standard brukes alle kjerner; lignende kommentarer vil bli sett på slike pakker selv når byggetiden er minimal.
Hvor selv en parallell bygging tar mer enn 15 SBU, på visse maskiner kan tiden være betydelig lengre selv når maskinen ikke bruker vekselminne. Spesielt vil forskjellige mikroarkitekturer bygge noen filer med forskjellige relative hastigheter, og dette kan introdusere forsinkelser når visse gjør at mål venter på at en annen fil blir opprettet. Hvor en stor build bruker mange C++ filer, prosessorer med simultan multithreading vil dele flytepunktsenheten og kan ta 45 % lengre tid enn ved å bruke fire 'prime' kjerner (målt på en intel i7 ved å bruke oppgavesett og holde andre kjerner inaktiv).
Noen pakker støtter ikke parallellbygg; for disse make kommandoen må spesifisere -j1. Pakker som er kjent for å pålegge slike grenser er markert i teksten.