CLI
Zakres weryfikacji
Treść zachowana z obecnego źródła. Publikacja dokumentacji nie oznacza ponownego potwierdzenia wszystkich komend, przykładów i deklaracji możliwości.
CLI Junexis tworzy projekty, sprawdza kod, generuje artefakty i prowadzi przez bardziej zaawansowane operacje.
Poziomy opisują ilość potrzebnej wiedzy, a nie uprawnienia. Każda komenda jest jawna, ale ścieżka początkująca potrzebuje tylko pierwszego, bezpiecznego podzbioru. Zobacz trzy poziomy pracy.
Podstawowe komendy
| Komenda | Poziom wejścia | Zastosowanie |
|---|---|---|
init |
początkujący | tworzy projekt z manifestem i minimalnym programem |
doctor |
początkujący | sprawdza układ projektu, źródło i konfigurację |
check |
początkujący | parsuje program i sprawdza semantykę |
build |
początkujący | generuje artefakty dla środowisk projektu |
analyze |
początkujący z prowadzeniem | zapisuje model analizy bez generowania kodu |
clean |
średniozaawansowany | usuwa wygenerowany stan projektu |
artifact-gate |
początkujący z prowadzeniem | uruchamia generatory i natywne kontrole zestawów narzędzi |
package |
początkujący z prowadzeniem | buduje i pakuje eksperymentalny pakiet systemu |
Operacje podpisu, zaufania, jawnego wyboru urządzenia, własnych integracji i szczegółowego wdrożenia należą do powierzchni eksperckiej. Ich pełne argumenty zawiera katalog poleceń.
flowchart LR
INIT["init"] --> DOC["doctor"]
DOC --> CHECK["check"]
CHECK --> ANALYZE["analyze"]
CHECK --> BUILD["build"]
BUILD --> GATE["artifact-gate"]
GATE --> PACKAGE["package"]
CLEAN["clean"] -.->|"resetuje wygenerowany stan"| DOC
Pełną listę dla używanego checkoutu pokazuje:
junexis --help
Pomoc konkretnej komendy:
junexis build --help
Projekt jako domyślny kontekst
Większość komend przyjmuje katalog projektu:
junexis doctor .\my-system
junexis check .\my-system
junexis build .\my-system
Jeżeli komenda junexis nie jest dostępna, środowisko nie jest jeszcze gotowe
do pracy użytkownika. Wróć do instalacji; nie zastępuj
publicznego interfejsu poleceniem uruchamiającym projekt kompilatora.
Wyniki
- kod i konfiguracja środowisk docelowych trafiają do
out/, - analiza systemu trafia do
out/analysis/, - mapy debugowania trafiają do
out/debug/, - ostatni poprawny wynik budowania jest opisany w
.junexis/state/latest-build.json.
Budowanie rozróżnia trzy listy środowisk:
requestedTargets— wskazane przez manifest lub--target,applicableTargets— rzeczywiście obecne w zadaniach programu,builtTargets— środowiska, dla których powstał kompletny artefakt.
W trybie pojedynczego pliku bez --target kompilator wybiera tylko środowiska
wynikające z adnotacji programu. Jawnie wskazane środowisko bez pasującego
zadania zatrzymuje budowanie diagnostyką B0003.
flowchart TB
BUILD["junexis build"] --> OUT["out/"]
BUILD --> STATE[".junexis/state/"]
OUT --> CODE["Kod środowisk docelowych"]
OUT --> ANALYSIS["Zapis analizy"]
OUT --> DEBUG["Mapy debugowania"]
OUT --> MANIFEST["Manifest artefaktów"]
STATE --> RECEIPT["Ostatnie poprawne budowanie"]
flowchart LR
REQUEST["Żądane środowiska<br/>manifest lub --target"] --> MATCH{"Czy istnieje<br/>pasujące zadanie?"}
SOURCE["Adnotacje zadań<br/>@server / @embedded / @report"] --> MATCH
MATCH -->|"tak"| BUILD["Generowanie"]
MATCH -->|"nie"| STOP["B0003<br/>bez publikacji wyniku"]
BUILD --> ACTUAL["builtTargets"]
Nie edytuj ręcznie out/. Zmiany, które mają przetrwać kolejne budowanie, umieszczaj
w źródłach, manifeście albo katalogu kodu należącego do użytkownika.