Konvensjoner som Brukes i denne Boken

Typografiske konvensjoner

For å gjøre ting enkelt å følge, brukes en rekke konvensjoner gjennom hele boka. Her er noen eksempler:

./configure --prefix=/usr

install-info: unknown option
`--dir-file=/mnt/lfs/usr/info/dir'

Uthevet

https://www.linuxfromscratch.org/

seamonkey-2.53.18.2

cat > $LFS/etc/group << "EOF"
root:x:0:
bin:x:1:
......
EOF

<REPLACED TEXT>

root

 

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:

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.