Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: okalousek 01. 07. 2020, 23:01:17
-
Budu teď pracovat na jednom menším projektu v Rustu na práci s konfiguračními soubory.
Chtěl bych mít bedýnku (knihovnu, pův. angl. crate) která by byla použitelná i jinými projekty.
Poté bych tam chtěl mít CLI část, která by šla používat např. skripty nebo na úpravu těch souborů z shellu.
Zatím vidím dvě možnosti jak ten projekt dělit:
1. A là Popsicle https://github.com/pop-os/popsicle (https://github.com/pop-os/popsicle) nebo https://github.com/pop-os/upgrade (https://github.com/pop-os/upgrade)
Popsicle:
Mají knihovnu v kořenu a gtk, cli frontendy v jednotlivých složkách
Používají Make
2. A là Fractal https://gitlab.gnome.org/GNOME/fractal (https://gitlab.gnome.org/GNOME/fractal)
Je tam komunikační backend a gtk frontend
Je to oddělené a Cargo.toml je jen workspace
Používá to Meson (nebudu používat, jen na ilustraci)
Takže cílová struktura:
1 (Popsicle):
[REPO ROOT]
src/lib.rs...
Cargo.toml (ta "bedýnka" té knihovny)
cli/
Cargo.toml (toho frontendu)
src/main.rs (cli)
Správa pomocí Makefile?
2 (a la fractal):
[REPO ROOT]
cli/
src/main.rs
Cargo.toml
lib/
src/lib.rs
Cargo.toml
Cargo.toml (jen workspace)
Co by z toho bylo ideální?
-
hlavni vec co muze jit pripadne do sveta je ta knihovna, takze ta je hlavni.
cli, gui je bud uplne samaostatny repozitar, nebo prilepek k te hlavni knihovne.
-
Asi toto nebyl moc šťastný příklad. Jen říkám, že buď se to bude dělat stylem Pop!_OS Popsicle, kde mají v kořeni repozitáře knihovnu a v něm ještě složku s binárkou, nebo to udělat jako https://github.com/google/evcxr (https://github.com/google/evcxr) kde mají jak knihovnu, tak CLI ve samostatné složce.
-
ted ja jsem zastance samostatnych repozitaru, samostatne repo pro libX, cli-X, gui-X.
a to bez ohledu na framework a jazyk.
-
ted ja jsem zastance samostatnych repozitaru, samostatne repo pro libX, cli-X, gui-X.
a to bez ohledu na framework a jazyk.
Tak ono to zase nebude nic velkého, takže nebude třeba samostatného repozitáře pro CLI.
-
Já bych taky spíš dal libku a app zvlášť - samostatný build a samostatný projekt. Udělat to tak od začátku je snadnější než to dělit dodatečně. Ostatní záleží na build systému a verzovacím systému. V některých buildovacích nástrojích IMHO půjde dát mezi projekty závislost, takže bude pak build app i knihovny proběhne v jediném kroku, stále ale s výhodou oddělení. Řekl bych, že se to vyplatí i u malých projektů protože to brání vzniku chaosu.
-
Dělat to samostatně hned od začátku je ale i velká nevýhoda - v takovém projektu většinou změna jedné věci vyžaduje i změnu jinde. Mít to v 2 repozitářích by znamenalo, že by pro tu změnu museli být třeba 2 commity, pull requesty, atd... Velké projekty spíš volí opak, viz třeba LLVM, Chromium, atd...
-
Jestli je to všechno v Rustu, rozhodně bych rovnou vyřadil z úvah Makefile a všechno dělal přes cargo.
Jestli je to jednoduchá aplikace, asi bych měl ze začátku všechno v jednom repozitáři. Úplne ze začátku bych libku i binárku držel v jedné crate (to jde bez problému), potom, kdyby k té libce třeba těch binárek vznikalo víc, tak bych uvažoval o tom založit si workspace, kde by byla jedna crate pro libku a další crates pro binárky, a až úplně nakonec, když by mě k tomu okolnosti donutily, bych to eventuelně rozdělil na víc repozitářů. Když už bych to stejně měl jako workspace s víc crates, už by to nebyla žádná velká práce. Ale dokud by mě okolnosti nenutily, udržoval bych to všechno v jednom repozitáři, vývoj bude výrazně snazší, a díky rozdělení do více crates v rámci jednoho workspace bych stejně byl nucen držet si víceméně jasné hranice mezi libkou a binárkami.
-
Jak vidno, co člověk to názor :) Jedna věc je správa kódu (repositáře) a druhá věc je kompilace (buildovací nástroj). Jelikož to bude dost záviset na nástrojích daného prostředí, tak se víc nemůžu vyjadřovat - Rust neznám :)
-
Dělat to samostatně hned od začátku je ale i velká nevýhoda - v takovém projektu většinou změna jedné věci vyžaduje i změnu jinde. Mít to v 2 repozitářích by znamenalo, že by pro tu změnu museli být třeba 2 commity, pull requesty, atd... Velké projekty spíš volí opak, viz třeba LLVM, Chromium, atd...
To by se dalo částečně řešit použitím git submodules. Knihovna odděleně, ale zároveň jako submodul v hlavním projektu.
-
Dělat to samostatně hned od začátku je ale i velká nevýhoda - v takovém projektu většinou změna jedné věci vyžaduje i změnu jinde. Mít to v 2 repozitářích by znamenalo, že by pro tu změnu museli být třeba 2 commity, pull requesty, atd... Velké projekty spíš volí opak, viz třeba LLVM, Chromium, atd...
To by se dalo částečně řešit použitím git submodules. Knihovna odděleně, ale zároveň jako submodul v hlavním projektu.
Já měl za to, že submoduly se prokázali jako slepá cesta. Používá to někdo intenzivněji?
-
Dělat to samostatně hned od začátku je ale i velká nevýhoda - v takovém projektu většinou změna jedné věci vyžaduje i změnu jinde. Mít to v 2 repozitářích by znamenalo, že by pro tu změnu museli být třeba 2 commity, pull requesty, atd... Velké projekty spíš volí opak, viz třeba LLVM, Chromium, atd...
To by se dalo částečně řešit použitím git submodules. Knihovna odděleně, ale zároveň jako submodul v hlavním projektu.
Já měl za to, že submoduly se prokázali jako slepá cesta. Používá to někdo intenzivněji?
A nejen slepá cesta ale peklo na užívání. Chápu využití když si to musí natahat nějaké projekty které to využívá ale k čemu to v tomto případě.
-
A nejen slepá cesta ale peklo na užívání. Chápu využití když si to musí natahat nějaké projekty které to využívá ale k čemu to v tomto případě.
K čemu? No co třeba k tomu aby to natahalo projekty které to používá?? Když bude libka a cli oddělené ve dvou projektech :D
-
A nejen slepá cesta ale peklo na užívání. Chápu využití když si to musí natahat nějaké projekty které to využívá ale k čemu to v tomto případě.
K čemu? No co třeba k tomu aby to natahalo projekty které to používá?? Když bude libka a cli oddělené ve dvou projektech :D
Spíše jsem to myslel tak, že když to potřebuje něco co ten člověk nevyvíjí ale to je s Cargo k ničemu.