makepp_sandboxes - Online in de cloud

PROGRAMMA:

NAAM

makepp_sandboxes -- Hoe een makepp-build te partitioneren

PRODUCTBESCHRIJVING

D: --doen-bouwen,
--niet bouwen,
--niet lezen,
--doe-lees, I: --in-sandbox,
--binnen-sandbox, O: --buiten de zandbak, S: --zandbak,
--sandbox-waarschuwing,
--sandbox-waarschuwing, V: --virtuele-sandbox

Er zijn een aantal redenen waarom u de bestandsstructuur voor een makepp zou willen partitioneren
bouwen:

1. Als u weet dat het grootste deel van de boom niet wordt beïnvloed door eventuele wijzigingen aan
bronbestanden sinds de vorige build, dan kun je makepp vertellen om die bestanden aan te nemen
in die delen van de boom zijn al up-to-date, dus niet eens impliciet
hun makefiles laden, laat staan ​​hun afhankelijkheden berekenen en controleren. (Opmerking
dat expliciet geladen makefiles echter nog steeds worden geladen.)

2. Als u meerdere makepp-processen hebt die toegang hebben tot dezelfde boom, dan wilt u raisen
een fout als u ontdekt dat twee gelijktijdige processen hetzelfde deel van het
boom, of dat ene proces een deel van de boom leest dat een gelijktijdig proces is
schrijven. Hoe dan ook, je hebt een raceconditie waarin de relatieve volgorde van gebeurtenissen
in twee gelijktijdige processen (wat niet gegarandeerd kan worden) kan het resultaat beïnvloeden.

Makepp heeft sandboxing-faciliteiten die beide problemen aanpakken.

sandboxing Opties
De volgende makepp-opties kunnen worden gebruikt om de sandbox-eigenschappen van de substructuur in te stellen
gegeven door pad en al zijn bestanden en potentiële bestanden:

--niet bouwen pad
--doen-bouwen pad
Stel de eigenschap "dont-build" in of reset deze. Elk bestand met deze eigenschappenset wordt verondersteld om
zijn al up-to-date en er worden geen build-controles uitgevoerd. De standaardwaarde wordt gereset
(dwz "do-build"), behalve als u een "RootMakeppfile" heeft, in welk geval alles
buiten de subboom-id "dont-build".

--zandbak pad
--in-sandbox pad
--binnen-sandbox pad
--buiten de zandbak pad
Stel de eigenschap "in-sandbox" in of reset deze. Er wordt een fout gegenereerd als makepp anders zou doen
schrijf een bestand met deze eigenschap reset. Bouwcontroles worden nog steeds uitgevoerd, tenzij de
De eigenschap "dont-build" is ook ingesteld. De standaardwaarde is ingesteld (dwz "in-sandbox"), tenzij
er zijn er --zandbak opties, in welk geval de standaard voor alle andere bestanden is
resetten (dwz "out-of-sandbox").

--sandbox-waarschuwing
--sandbox-waarschuwing
Downgrade schendingen van "in-sandbox" en "dont-read" naar waarschuwingen in plaats van fouten.
Dit is handig als er honderden overtredingen zijn, zodat je ze allemaal kunt verzamelen
in één run en neem passende corrigerende maatregelen. Anders zie je alleen
één overtreding per makepp-aanroep, en je weet niet hoeveel er nog over zijn tot
ze zijn allemaal opgelost.

--niet lezen pad
--doe-lees pad
Stel de eigenschap "niet lezen" in of reset deze. Er wordt een fout gegenereerd als makepp anders zou doen
lees een bestand met deze eigenschappen ingesteld. De standaardwaarde wordt gereset (dwz "do-read").

--virtuele-sandbox
Herschrijf geen build-info van bestanden die niet door dit makepp-proces zijn gemaakt. Dit
is handig bij het uitvoeren van gelijktijdige makepp-processen met overlappende sandboxen, en u
er zeker van zijn dat geen twee processen hetzelfde doelwit zullen proberen te bouwen. Makepp zal
onthoud dan van het cachen van aanvullende informatie over bestanden die het leest, omdat
er kunnen andere gelijktijdige lezers zijn.

Elk van deze 3 eigenschappen is van toepassing op de gehele substructuur, inclusief bestanden die dat niet doen
toch bestaan. Meer specifieke paden overschrijven minder specifieke paden. Een opgegeven pad kan een
individueel dossier, ook als het dossier nog niet bestaat.

Als een eigenschap zowel is ingesteld als opnieuw ingesteld op exact hetzelfde pad, dan is de optie die verschijnt
uiterst rechts op de opdrachtregel heeft voorrang.

sandboxing For Versnelling
Als u wilt voorkomen dat makepp tijd verspilt aan het verwerken van bestanden waarvan u weet dat ze al bestaan
up-to-date (in het bijzonder bestanden die zijn gegenereerd door een andere build-tool dan makepp),
harte --niet bouwen is de optie voor jou.

Verreweg het meest voorkomende geval voor zo'n optimalisatie is dat je weet dat niet alles
op of onder de startmap is al up-to-date. Hieraan kan worden gecommuniceerd
makepp gebruiken "--niet bouwen /. --doen-bouwen .".

sandboxing For gelijktijdig processen
Een techniek die de latentie bij het bouwen kan verminderen, is door meerdere makepp-processen te laten werken
aan dezelfde boom. Dit is een stuk moeilijker te beheren dan het gebruik van de -j keuze,
maar het kan ook aanzienlijk effectiever omdat:

· Bij sandboxing kunnen de processen bijvoorbeeld via een job op meerdere hosts draaien
wachtrij systeem. Het verhogen van de -j limiet put uiteindelijk de CPU-bronnen van een
enkele host, en kan de build zelfs vertragen vanwege overmatige procesvorken.

· -j parallelliseert momenteel sommige tijdrovende taken van makepp, zoals laden
makefiles, scannen, impliciete afhankelijkheden opbouwen tijdens het scannen en controleren
afhankelijkheden.

Het grootste risico bij deze aanpak is dat de build niet-deterministisch kan worden als
processen die gelijktijdig kunnen zijn, interageren met elkaar. Dit leidt tot bouwsystemen
die sporadisch onjuiste resultaten opleveren, en zonder eenvoudig mechanisme om te bepalen waarom
het gebeurt.

Om dit risico aan te pakken, is het raadzaam om de boom te verdelen over gelijktijdige processen
zodanig dat als een proces op onjuiste wijze toegang krijgt tot het bestandssysteem, er een fout is
onmiddellijk deterministisch verhoogd. Normaal gesproken wordt dit bereikt door aan elk toe te wijzen
gelijktijdig proces een "sandbox" waarin geschreven mag worden, waarbij de sandboxen van nr
twee gelijktijdige processen kunnen elkaar overlappen.

Bovendien markeert elk proces de sandboxen van andere mogelijk gelijktijdige processen
als "niet lezen". Als een proces een bestand leest, is een ander gelijktijdig proces verantwoordelijk
voor schrijven (en die daarom misschien nog niet geschreven zijn), dan ontstaat er een fout
per direct plannen.

sandboxing For Sequential processen
Wanneer de build is gepartitioneerd voor gelijktijdige makepp-processen, is er meestal ook een
sequentiële relatie tussen verschillende procesparen. Er kan bijvoorbeeld een
tientallen gelijktijdige compileerprocessen, gevolgd door een enkel linkproces dat niet kan beginnen
totdat alle compilatieprocessen zijn voltooid. Dergelijke opeenvolgende relaties moeten zijn
afgedwongen door welk mechanisme dan ook dat de verschillende makepp-processen orkestreert (bijvoorbeeld
het wachtrijsysteem).

Wanneer processen een bekende sequentiële relatie hebben, is het normaal gesproken niet nodig om een
fout wanneer ze toegang krijgen tot hetzelfde deel van de boom, omdat het resultaat toch is
deterministisch.

Het is echter over het algemeen gunstig om te specificeren --niet bouwen opties voor de afhankelijke persoon
proces (het koppelingsproces in ons voorbeeld) dat het op de hoogte stelt van de gebieden die al zijn uitgevoerd
bijgewerkt door de vereiste processen (de compileertaken in ons voorbeeld). In deze
Op deze manier vermijden we het meeste onnodige werk van null-building doelen die rechtvaardig waren
bijgewerkt.

Gebruik makepp_sandboxes online met behulp van onworks.net-services