Si j'ai bien suivi ça gère des sources git, quel est alors la différence avec un gestionnaire de multiple git tel que Android repo ?
Mélanger gestionnaire de source et build système ma toujours parue un mauvais mélange en dehors des cas particuliers d'un méta build système comme yocto mais on est plus dans le même cas d'usage, on fait de la création de distro pas de dev de code.
Alors pas exactement. Tu as besoin d'un fichier shipp.json dans le dépôt que tu cible en tant que dépendance pour pouvoir le compiler.
Ce n'est pas un "build system", le fichier shipp.json indique la commande de build et install, donc tu peux utiliser ce que tu veux: CMake, Ninja, Meson, … D'ailleurs, Shipp est écrit en Rust, et son shipp.json indique la commande cargo build et cargo install, donc ce n'est pas limité à C/C++.
Dans mes projets C/C++ j'avais pour habitude d'utiliser CMake et de add_subdirectory un git submodule pour gérer mes dépendances directes. Pour les dépendances transitive, on se retrouve avec des nested git submodule, et de la duplication de build à tord et à travers, ça devient très vite un cauchemar.
La, shipp va aller git clone/git pull les répos qui vont bien dans .shipp/deps/<dep name> et les installer dans .shipp/dist. On se retrouve donc avec un dossier .shipp/dist qui a les dossiers include, lib, bin, share, etc… que tu peux utiliser pour configurer correctement les flags -I et -L de ton compilateur par exemple.
Shipp au final, c'est juste ça : récupérer les dépendances, utiliser leur build system sans avoir de la grosse plomberie a faire pour l'intégrer au tient, compiler tout ça et compiler ton projet avec ton propre build system aussi.
# Question ?
Posté par Tangi Colin . Évalué à 2.
Si j'ai bien suivi ça gère des sources git, quel est alors la différence avec un gestionnaire de multiple git tel que Android repo ?
Mélanger gestionnaire de source et build système ma toujours parue un mauvais mélange en dehors des cas particuliers d'un méta build système comme yocto mais on est plus dans le même cas d'usage, on fait de la création de distro pas de dev de code.
[^] # Re: Question ?
Posté par David Delassus (site web personnel) . Évalué à 2.
Alors pas exactement. Tu as besoin d'un fichier
shipp.jsondans le dépôt que tu cible en tant que dépendance pour pouvoir le compiler.Ce n'est pas un "build system", le fichier
shipp.jsonindique la commande de build et install, donc tu peux utiliser ce que tu veux: CMake, Ninja, Meson, … D'ailleurs, Shipp est écrit en Rust, et sonshipp.jsonindique la commandecargo buildetcargo install, donc ce n'est pas limité à C/C++.Dans mes projets C/C++ j'avais pour habitude d'utiliser CMake et de
add_subdirectoryun git submodule pour gérer mes dépendances directes. Pour les dépendances transitive, on se retrouve avec des nested git submodule, et de la duplication de build à tord et à travers, ça devient très vite un cauchemar.La, shipp va aller git clone/git pull les répos qui vont bien dans
.shipp/deps/<dep name>et les installer dans.shipp/dist. On se retrouve donc avec un dossier.shipp/distqui a les dossiersinclude,lib,bin,share, etc… que tu peux utiliser pour configurer correctement les flags-Iet-Lde ton compilateur par exemple.Shipp au final, c'est juste ça : récupérer les dépendances, utiliser leur build system sans avoir de la grosse plomberie a faire pour l'intégrer au tient, compiler tout ça et compiler ton projet avec ton propre build system aussi.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# Commentaire de vendredi
Posté par Maclag . Évalué à 4.
C, C++ et Rust sont tous les 3 considérés comme des langages de bas niveau.
Si on en vient à choisir le Rust pour faire un outil pour les 2 autres, il faut y voir un signe ou pas?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.