Le topic de la programmation: Et envoyez des sioux!

**gros_bidule** · 02/03/2022, 21h56

Question de gros noob en C/C++, mais il n'y a pas moyen d'unifier tout ça en déléguant le build à Gradle ?

**Patate** · 03/03/2022, 06h23

Bon c'est un truc de noob je pense

En gros je voudrais utiliser cette librairie : https://github.com/thebracket/rltk

Je vois qu'il conseil d'utiliser vcpkg pour installer les dépendances. Je me renseigne et c'est vrai que c'est sympa un gestionnaire de dépendances. J'ai testé un peu Rust et Cargo c'est bien pratique.

J'ai installé vcpkg et les librairies demandées. Sachant que celle qui m'interesse n'est pas dans les dépôt, dommage. Donc je clone le git et compile. Je me retrouve avec un librltk.a dans le dossier master.

Voici mon CMakeLists.txt :

Code:

cmake_minimum_required(VERSION 3.0.0)
project(rl VERSION 0.1.0)

include_directories(/opt/vcpkg/installed/x64-linux/include/) #include où VCPKG installe les lib
include_directories(/home/patate/devs/lib/rltk/rltk) #Là où j'ai compilé la lib qui m'intéresse
link_directories(/opt/vcpkg/installed/x64-linux/lib/) #les lib où VCPKG installe les lib
link_directories(/home/patate/devs/lib/rltk)

find_library(RLTK_LIB NAMES rltk PATHS /home/patate/devs/lib/rltk)

find_package(ZLIB REQUIRED)
find_package(SFML 2 COMPONENTS system window graphics REQUIRED)
find_package(cereal REQUIRED)

add_executable(rl main.cpp)

target_link_libraries(rl sfml-system sfml-graphics sfml-window ${RLTK_LIB})

Bon j'ai avancé, je crois qu'il trouve tout mais j'ai encore une erreur de link au niveau de la SFML dans la lib rltk :

Code:

[main] Building folder: rl 
[build] Starting build
[proc] Executing command: /usr/bin/cmake --build /home/patate/devs/cpp/rl/build --config Debug --target all -j 10 --
[build] [1/1 100% :: 0.554] Linking CXX executable rl
[build] FAILED: rl 
[build] : && /bin/c++ -g -rdynamic CMakeFiles/rl.dir/main.cpp.o -o rl -L/opt/vcpkg/installed/x64-linux/lib   -L/home/patate/devs/lib/rltk -Wl,-rpath,/opt/vcpkg/installed/x64-linux/lib:/home/patate/devs/lib/rltk  /opt/vcpkg/installed/x64-linux/debug/lib/libsfml-system-s-d.a  /opt/vcpkg/installed/x64-linux/debug/lib/libsfml-graphics-s-d.a  /opt/vcpkg/installed/x64-linux/debug/lib/libsfml-window-s-d.a  /home/patate/devs/lib/rltk/librltk.a  /opt/vcpkg/installed/x64-linux/debug/lib/libsfml-system-s-d.a  -lpthread  -lrt  -ludev  -lOpenGL  -lX11  -lXrandr  /opt/vcpkg/installed/x64-linux/debug/lib/libfreetyped.a  /opt/vcpkg/installed/x64-linux/debug/lib/libbz2d.a  /opt/vcpkg/installed/x64-linux/debug/lib/libpng16d.a  /opt/vcpkg/installed/x64-linux/debug/lib/libz.a  -lm  /opt/vcpkg/installed/x64-linux/debug/lib/libbrotlidec-static.a  /opt/vcpkg/installed/x64-linux/debug/lib/libbrotlicommon-static.a && :
[build] /usr/bin/ld: /home/patate/devs/lib/rltk/librltk.a(gui.cpp.o): attention: réadressage sur « _ZTVN2sf11VertexArrayE » dans la section en lecture seule « .text._ZNSt10_HashtableIiSt4pairIKiN4rltk7layer_tEESaIS4_ENSt8__detail10_Select1stESt8equal_toIiESt4hashIiENS6_18_Mod_range_hashingENS6_20_Default_ranged_hashENS6_20_Prime_rehash_policyENS6_17_Hashtable_traitsILb0ELb0ELb1EEEE12_Scoped_nodeD2Ev[_ZNSt10_HashtableIiSt4pairIKiN4rltk7layer_tEESaIS4_ENSt8__detail10_Select1stESt8equal_toIiESt4hashIiENS6_18_Mod_range_hashingENS6_20_Default_ranged_hashENS6_20_Prime_rehash_policyENS6_17_Hashtable_traitsILb0ELb0ELb1EEEE12_Scoped_nodeD5Ev] »
[build] /usr/bin/ld : /home/patate/devs/lib/rltk/librltk.a(rltk.cpp.o) : dans la fonction « rltk::run(std::function<void (double)>) » :
[build] /home/patate/devs/lib/rltk/rltk/rltk.cpp:92 : référence indéfinie vers « sf::Window::isOpen() const »
[build] /usr/bin/ld : /home/patate/devs/lib/rltk/rltk/rltk.cpp:97 : référence indéfinie vers « sf::Window::pollEvent(sf::Event&) »
[build] /usr/bin/ld : /home/patate/devs/lib/rltk/rltk/rltk.cpp:97 : référence indéfinie vers « sf::Window::pollEvent(sf::Event&) »
...

Là j'ai du mal à voir le problème. librltk.a a besoin de la SFML mais pourtant je lui donne dans le CMake. Les fichier .so doivent être présent dans le dossier de build ?!

**Cwningen** · 03/03/2022, 10h55

Peut-être un problème d'ordre des bibliothèque sur la ligne de commande ? Si tu crées un "imported target" pour rltk avec une dépendance sur sfml, ça marche mieux ? Ou alors on peut améliorer le script cmake de rltk pour qu'il installe ce qu'il faut pour un find_package.

**Anonyme20240202** · 03/03/2022, 13h12

Bon j'ai retrouvé mon projet Vulkan, si jamais ça peut aider:

Je me souviens que j'en ai chié avec ce truc, à mettre dans les options CMake:

Code:

-DCMAKE_TOOLCHAIN_FILE=C:\dev\vcpkg/scripts/buildsystems/vcpkg.cmake

Mon CMake est tout simple

Code:

cmake_minimum_required(VERSION 3.19)
project(test_cpp)

set(CMAKE_CXX_STANDARD 20)

find_package(glfw3 REQUIRED)
find_package(Vulkan REQUIRED)

add_executable(test_cpp main.cpp)

target_link_libraries(test_cpp glfw Vulkan::Vulkan)

- - - Mise à jour - - -

Et mon vcpkg ressemble à ça:

Code:

PS C:\dev\vcpkg> .\vcpkg.exe list
glfw3:x64-windows                                  3.3.3            GLFW is a free, Open Source, multi-platform libr...
glfw3:x86-windows                                  3.3.3            GLFW is a free, Open Source, multi-platform libr...
vulkan-headers:x64-windows                         1.2.157          Vulkan header files and API registry
vulkan:x64-windows                                 1.1.82.1-1       A graphics and compute API that provides high-ef...
vulkan:x86-windows                                 1.1.82.1-1       A graphics and compute API that provides high-ef...

**Mr Slurp** · 03/03/2022, 14h11

Envoyé par Patate

[...]

Parce que le projet que tu intègres est un projet CMake, ce projet export très probablement une target CMake lors de la phase "install". Si le package exporte bien tout comme il faut, tu devrais être en mesure de le trouver grace à find_package et tu pourra ainsi l'utiliser comme la zlib ou cereal qui sont listé dans ton cmake.

Code:

    set( RLTK_LIB_ROOT "<dossier>")
    find_package(RLTK_LIB REQUIRED)

RLTK semble être une lib statique, ce qui implique que lorsque tu link dessus, il faut obligatoirement que tu link avec les librairies que elle même a besoin pour linker, c'est justement tout le but de la target qu'elle est sensé générer puisque cette dernière définie toutes les options de compilation et de linkage nécessaires.
Les erreur que tu as le montre bien, c'est le code de RLTK qui ne trouve pas les symboles externes qu'il utilise, justement parce que au moment du linkage de ton projet, celui ci ne connais pas les "Third Party" de RLTK

**Cwningen** · 03/03/2022, 14h20

Envoyé par Mr Slurp

Parce que le projet que tu intègres est un projet CMake, ce projet export très probablement une target CMake lors de la phase "install". Si le package exporte bien tout comme il faut, tu devrais être en mesure de le trouver grace à find_package et tu pourra ainsi l'utiliser comme la zlib ou cereal qui sont listé dans ton cmake.

rltk n'exporte pas, mais cadeau :

Spoiler Alert!

Patch pour le CMakeLists.txt de rltk :

Code:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index a67d12f..e965f06 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,7 +1,6 @@
-cmake_minimum_required(VERSION 3.1)
+cmake_minimum_required(VERSION 3.8)
 project("rltk")
 
-set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${PROJECT_SOURCE_DIR}/cmake_modules")
 set(CMAKE_CXX_STANDARD 14)
 set(CMAKE_CXX_STANDARD_REQUIRED on)
 
@@ -27,22 +26,15 @@ add_library(rltk    rltk/rltk.cpp
                                        rltk/rexspeeder.cpp
                                        rltk/scaling.cpp)
 target_include_directories(rltk PUBLIC
-               "$<BUILD_INTERFACE:${SFML_INCLUDE_DIR}>"
-               "$<BUILD_INTERFACE:${CEREAL_INCLUDE_DIR}>"
-               "$<BUILD_INTERFACE:${ZLIB_INCLUDE_DIRS}>"
-               )
-target_link_libraries(rltk PUBLIC ${ZLIB_LIBRARIES} ${SFML_LIBRARIES})
+       $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>
+       $<INSTALL_INTERFACE:include>)
+target_link_libraries(rltk PUBLIC ZLIB::ZLIB sfml-system sfml-window sfml-graphics cereal::cereal)
 if(NOT MSVC) # Why was this here? I exempted the wierd linker flags
        target_compile_options(rltk PUBLIC -O3 -Wall -Wpedantic -march=native -mtune=native -g)
 else()
        target_compile_options(rltk PUBLIC /W3 /EHsc)
 endif()
 
-install (TARGETS rltk
-               ARCHIVE DESTINATION lib
-               LIBRARY DESTINATION lib
-               RUNTIME DESTINATION bin)
-
 set(RLTK_HEADERS
                rltk/astar.hpp
                rltk/colors.hpp
@@ -72,9 +64,17 @@ set(RLTK_HEADERS
                rltk/visibility.hpp
                rltk/xml.hpp)
 
-install(FILES ${RLTK_HEADERS}
-               DESTINATION "include/rltk"
-               )
+set_target_properties(rltk PROPERTIES PUBLIC_HEADER "${RLTK_HEADERS}")
+
+install (TARGETS rltk EXPORT rltk-config
+               ARCHIVE DESTINATION lib
+               LIBRARY DESTINATION lib
+               RUNTIME DESTINATION bin
+               PUBLIC_HEADER DESTINATION include/rltk)
+install (EXPORT rltk-config
+               NAMESPACE rltk::
+               DESTINATION lib/cmake/rltk)
+
 
 # Examples

Ensuite dans ton CMakeLists.txt à toi, tu fais

Code:

find_package(rltk REQUIRED)

...

target_link_libraries(rl rltk::rltk)

**Mr Slurp** · 03/03/2022, 14h35

Envoyé par Cwningen

rltk n'exporte pas, mais cadeau :

Monsieur!

**Patate** · 04/03/2022, 06h04

Woh ! Merci pour vos réponses vous assurez !

Je regarde ça et je reviens avec plein de questions

**Patate** · 04/03/2022, 06h22

Bon j'essai de faire ça bien et approfondir mes connaissance de git (qui sont presque à 0)... J'ai fork le dépôt rltk, clone sur mon pc, créer un fichier patch avec le contenu de ton post Cwningen. Mais lors de l'appliquer avec git apply patch_cmake.patch
J'ai un "error: patch corrompu à la ligne 59" qui correspond à la fin du fichier, j'ai beau virer la fin, j'ai toujours ce message avec comme ligne la dernière du fichier.

Est-ce que tu as c/c ton diff complet et je peux utiliser git ou bien tu as juste c/c le principal ? Dans ce cas je modifie le CMakeLists à la main.

**Nattefrost** · 04/03/2022, 09h32

Faut pas utiliser l'utilitaire "patch" pour ce genre de choses ?

**Anonyme20240202** · 04/03/2022, 10h04

Vérifie déjà que t'arrives à compiler et run rltk en stand alone, si ça fonctionne pas c'est que le problème est au niveau de l'install de SFML sinon c'est que ton cmake merde.

Regarde mon précédent post et poste ton setup vcpkg & cmake.

Vérifie que tu as bien les targets X64 ou X86 selon ton compilateur. Parce que si t'as la mauvaise target CMake va trouver le package mais ça va planter au link voire au runtime (?)

Ensuite s'pas compliqué, si les exemples de ce machin RLTK fonctionnent y'a aucune raison pour que ça ne fonctionne pas avec toi.

Donc tu peux simplement ouvrir RLTK, et linker contre les sources au lieu d'essayer d'exporter/installer RLTK

Une fois que t'auras vérifié que tout ça fonctionne proprement tu pourras te prendre la tête à essayer de créer un cmake correct.

Mais ils ont l'air un peu amateur RLTK donc ça a l'air d'être un petit bordel et ça a l'air pénible à fix. Sans compter que t'es sous windows (windows c'est une horreur pour dev) et que t'as l'air d'utiliser WSL donc là ça rajoute de la complexité dans la résolution des dépendances j'imagine.

Mais ils ont pas l'air d'exporter/d'exposer leur lib proprement. Et puis les chemins relatifs dans les headers (.hpp), très très sale, et leur CMake fait pas vraiment les choses de manière moderne.

From scratch chez moi:

Si tu veux vraiment partir vers un "vrai" package. Je te conseil de démarrer chez toi avec une dummy library et un dummy consumer et t'essayes de link les deux. Une fois que t'auras un bon setup d'example avec une lib (qui fait juste hello world genre) et quelqu'un qui la consomme reproduit ça avec RLTK mais bon comme je le disais la qualité a pas l'air ouf, mais bon au moins si tu corriges leurs trucs tu pourras push dans leur repo fièrement haha

Code:

PS C:\dev\vcpkg> .\vcpkg.exe list
[...]
cereal:x64-windows                                 1.3.0            a header-only C++11 serialization library (built...
sfml:x64-windows                                   2.5.1#10         Simple and fast multimedia library
zlib:x64-windows                                   1.2.11#10        A compression library
[...]

**Cwningen** · 04/03/2022, 10h31

Le forum a du modifier les espaces. Ajoute une ligne vide à la fin et utilise l'option --ignore-whitespace de git apply. Ou applique le patch à la main comme ça tu revois en détails les changements.

Pour bien comprendre, les changements sont :

On retire de l'ajout des scripts cmake fournis par rltk : sfml et cereal sont fournis avec leurs propres scripts qui marchent bien (chez moi).
On retire les dossiers include des dépendances ce sera fait par target_link_libraries à la place.
On ajoute les dossiers include de rltk (build et install), pour que l'utilisateur de la bibliothèque n'est pas à le faire lui-même.
On remplace les nom de fichiers par les "targets" pour target_link_libraries, comme ça cmake ajoute tout ce que les dépendances demandent, pas seulement les "-lsomelib".
On ajoute les headers dans la propriété PUBLIC_HEADER pour les installer plus facilement.
On installe un export de la config, pour que l'utilisateur puisse facilement importer le target rltk.

**Anonyme20240202** · 04/03/2022, 12h12

Ouais voilà Cwningen a raison on parlait de la même chose j'avais pas lu son patch, donc, au lieu de leur cmake infâme de 200 lignes, tu peux simplement avoir ça (moderne)

Là je fais l'exemple rapide sans importer, directement dans les sources rtlk

Code:

cmake_minimum_required(VERSION 3.1)
project("rltk")

set(CMAKE_CXX_STANDARD 14)

find_package(ZLIB REQUIRED)
find_package(SFML 2 COMPONENTS system window graphics REQUIRED)
find_package(Cereal REQUIRED)

add_library(
        rltk
        rltk/rltk.cpp
        rltk/texture_resources.cpp
        rltk/color_t.cpp
        rltk/virtual_terminal.cpp
        rltk/rng.cpp
        rltk/geometry.cpp
        rltk/input_handler.cpp
        rltk/font_manager.cpp
        rltk/gui.cpp
        rltk/layer_t.cpp
        rltk/gui_control_t.cpp
        rltk/virtual_terminal_sparse.cpp
        rltk/ecs.cpp
        rltk/xml.cpp
        rltk/perlin_noise.cpp
        rltk/rexspeeder.cpp
        rltk/scaling.cpp
)

target_link_libraries(rltk PUBLIC ZLIB::ZLIB sfml-system sfml-window sfml-graphics cereal)

add_executable(patate patate_custom.cpp)
target_link_libraries(patate rltk)

Ca tu peux le copier coller et ça marche d'office. Dans un deuxième temps tu pourras faire comme Cwningen explique et faire l'export pour que l'utilisateur puisse import.
A noter, je suis peut être pas à jour mais chez moi cereal::cereal n'est pas défini j'ai que cereal, chui p'têt en retard niveau version de la lib, bref

- - - Mise à jour - - -

Et tu peux même utiliser "add_subdirectory" quand t'as les sources comme ça, même pas besoin de faire un export cmake si tu veux rester simple

Code:

cmake_minimum_required(VERSION 3.20)
project(test_rtlk)

set(CMAKE_CXX_STANDARD 20)

add_subdirectory(rltk)

add_executable(patate_test main.cpp)
target_link_libraries(patate_test rltk)

- - - Mise à jour - - -

Tu pourrais en faire un git submodule par exemple

**Cwningen** · 04/03/2022, 15h53

Envoyé par Kamikaze

Ouais voilà Cwningen a raison on parlait de la même chose j'avais pas lu son patch, donc, au lieu de leur cmake infâme de 200 lignes, tu peux simplement avoir ça (moderne)

Je ne le trouve pas infâme. C'est justement parce que je l'ai trouvé simple que j'ai tenté le patch.

**Anonyme20240202** · 04/03/2022, 16h27

Disons verbeux et pas super à jour, pas infâme

**Patate** · 05/03/2022, 06h35

Merci ! Je regarde ça dans le week-end !

**Patate** · 05/03/2022, 07h24

Merci Kamikaze d'avoir pris le temps, je comprend mieux le fonctionnement ! Les exemples fonctionnaient bien chez moi de base donc j'ai essayé de m'inspiré de son cmake pour créer mon projet avant de venir ici. Sinon je suis sous linux (arch).

Au final j'ai utilisé le patch de Cwingen (Merci !!!) que j'ai copié à la main, même avec l'option, j'ai toujours eu le message "patch corrompu". Et j'ai pu build mon projet extérieur !

Encore merci !

Petite question (pour les linuxiens) :
Je me trouve ici en console : ~/devs/cpp/rl/ <- A ce niveau j'ai mes sources et cmakelists.txt

ls

Code:

assets
build
CMakeLists.txt
main.cpp

Dans le main.cpp, il accède au dossier assets pour des ressources (font, etc) avec cette ligne et un chemin relatif :

Code:

init(config_simple("../assets", 80, 50, "RLTK Hello World", "8x8"));

Ce qui est marrant c'est que le contexte change suivant d'où je lance le programme :

Ne fonctionne pas : "what(): Font directory does not exist."

Code:

./build/rl

Fonctionne :

Code:

cd build && ./rl

Le cwd du programme est celui de la console ? Pas celui où il se trouve dans l'arborescence ?

**Anonyme20240202** · 05/03/2022, 08h47

Ah! Sous Linux il vaut vraiment mieux se passer complètement de vcpkg. Y'a de bien meilleures alternatives, ne serait que le package manager de ta distrib. En plus d'expérience je vois souvent que les packages sous vcpkg sont pas très à jours et surtout il manque pas mal de trucs.
Je me suis dit que tu devais être sous WSL car je voyais des chemins unix et du vcpkg en même temps.

Sinon ouais quand tu fais .. c'est à partir du répertoire courant.

Leur code est pas de super, super bonne qualité de manière générale. Perso je recommande de toujours utiliser des chemins absolu, donc genre:

(Là je suis sous windows car depuis le début (avec vcpkg) je croyais que t'étais sous windows donc)

Code:

int main() {
    init(config_simple(R"(C:\Users\ASUS-ROG\CLionProjects\patate\assets)", 80, 25, "RLTK Hello World", "8x16", false));
    run(tick);

    return 0;
}

Mais sinon ce qu'on voit aussi très souvent c'est de récupérer l'argument de main, le premier argument (std::cout << argv[0]) contient toujours le chemin vers l'exécutable, et donc en partant de là tu peux garantir que ça fonctionne quelque soit l'endroit d'où c'est appelé.
D'ailleurs si tu regardes dans tes services sous arch linux ou n'importe quelle distrib, la plupart des daemon/services (programmes qui s'exécutent dans le background) sont géré par un super service (genre systemd) qui va spécifier le répertoire d'exécution.

Du genre

Code:

[Service]
WorkingDirectory=/www

(tout ça pour dire que s'pas nécessairement trivial et qu'effectivement faut se décider sur un contexte)

Bon et des fois je vais un peu vite en besogne à lacher des "code infame", c'est de l'hyperbole, j'exagère. Juste quelques trucs qui me sautent aux yeux.

Donc là direct effectivement j'avais vu des chemins relatif j'étais pas content,

Code:

init(config_simple("../assets", 80, 25, "RLTK Hello World", "8x16", false));

ensuite on voit qu'ils passent leur argument par copie au lieu d'une référence dans plusieurs de leurs méthodes,

Code:

register_font_directory(const std::string path)

dans leurs exemples ils font références aux headers de manière relative alors que ça devrait être une référence absolue avec le cmake/le build qui s'occuper d'exposer le include folder. (target_include_directories)

Code:

#include "../../rltk/rltk.hpp"

Et ils utilisent le system call "stat" pour vérifier l'existence du fichier, qui à ma surprise fonctionne sous windows mais s'pas très cross platform, feraient mieux d'utiliser une abstraction qui fait les choses proprement.

Code:

    struct stat buffer;
    return (stat (filename.c_str(), &buffer) == 0);

M'enfin bref je chipote, c'est simplement que ça me démange de refactor et de faire un commit dans leur repo haha

**Cwningen** · 05/03/2022, 10h48

Envoyé par Kamikaze

Mais sinon ce qu'on voit aussi très souvent c'est de récupérer l'argument de main, le premier argument (std::cout << argv[0]) contient toujours le chemin vers l'exécutable, et donc en partant de là tu peux garantir que ça fonctionne quelque soit l'endroit d'où c'est appelé.

Non, ce n'est pas fiable. argv[0] est un argument comme un autre, il peut valoir n'importe quoi. Même dans le cas le plus usuel où l’exécutable est dans le PATH, ça ne marche pas. argv[0] contiendra seulement le nom de l'exécutable sans le chemin.

Si tu dois charger des fichiers de données ou de configuration, le mieux sur Linux, c'est de suivre cette spécification. Évidemment, si tu veux être cross-platform, il faudra un autre comportement pour les autres OS.

**Anonyme20240202** · 05/03/2022, 16h22

Ah tout à fait, pas rigoureux de ma part. C'tait plus une remarque sur ce que je vois parfois, perso je consomme jamais argv[0] je suis toujours en chemins absolus (autant que possible) et de temps en temps je passe un unique argument au main avec un fichier de config, ça s'arrête là pour mon expérience avec les arguments pour main (puis bon parfois un --version voire --help)

**Patate** · 05/03/2022, 16h35

Intéressant tout ça !
D'ailleurs vous utilisez un gestionnaire de dépendance en c++ ? J'ai l'impression qu'il y en a beaucoup mais pas vraiment un qui perce. J'ai utilisé vcpkg parce qu'il revient souvent. J'ai testé Conan vite fait qui est plus simple à utiliser (pour moi qui suis une brèle en cmake) mais il n'y avait pas tout dans les dépots.

Après utiliser des chemins absolus c'est risqué le jour où tu déplaces tes ressources ou autres non ? Tu dois modifier ton code source et recompiler.

**Anonyme20240202** · 05/03/2022, 19h24

Y'a pas mal de conférences/présentations à ce sujet. C'est un des "problèmes" (rien d'insurmontable hein) en C++. Y'a pas vraiment d'unification à ce niveaux.

Tu peux choisir un peu ce que tu veux selon tes besoins. Je recommande de démarrer avec le package manager de ta distrib c'est une très bonne option.

Et une option populaire:

https://www.jetbrains.com/lp/devecos...libraries-in-C

Pour Conan tu peux faire un truc custom et fournir les packages toi même si y'a pas ce dont t'as besoin par défaut.

Donc si ton besoin, c'est un dev solo qui veut se faire plaisir, pars sur le package manager de ta distrib. C'est même une option viable pour une team pro hein, mais la je suppose que tu test des trucs en solo de ce qu'on a vu.

Si un package un peu obscur n'est pas dispo (ou pas la version que tu veux), tu peux simplement l'obtenir toi même, compiler depuis les sources ou autre, c'est aussi un bon entraînement (c'est ce que t'as fait pour rltk t'façon, tu connais).

Surtout si t'es sur Archlinux ça devrait être très propre niveau repos dispo

Concernant les chemins absolus là tu parles d'un truc hardcodé qui demande un redéploiement (compile + distribue ton truc), s'pas vraiment lié à absolu vs relatif.
Le problème avec "../../" c'est que tu ne sais pas s'il va être consumé maintenant ou être combiné à quelque chose par exemple, ça rend pénible la compréhension.

Donc bref, y'a jamais besoin de faire ../../asset ou autre
Tu définis le répertoire où tu travail et tu nommes tout à partir de là.

Donc dans un fichier de config "asset", ou "somewhere/asset" (sous entendu par rapport à un chemin connu, donc ('executable'/asset), donc bien sûr c'est "relatif", tout est relatif) voire même un truc vis à vis du système "/tmp/asset"

----

Et y'a pas besoin d'être "fort" en CMake pour ça

Le flow c'est find_package(mon_truc), qui fonctionne dans la grande majorité des cas (si le package n'est pas trouvé tu y vas à grand coup de "apt install mon_truc-dev" (généralement y'a le suffixe "dev" ou "devel" parce que tu veux pas un binaire executable mais consumer la lib))

Et dans le cas où les mecs n'exporte pas de machin cmake, faudra le faire à l'ancienne ouais

Mais comme tu le vois tous les projets un tant soit peu populaire (genre sfml, etc.) bah y'a le package cmake kivabien

**Raplonu** · 06/03/2022, 12h01

J’utilise conan tous les jours, utilisation de dépendances, déploiement de package et gestion d'un repo privé. Je trouve que ce gestionnaire a vraiment une valeur ajoutée (Bon, j'ai pas trop testé les autres non plus... ).

Par contre, il encore est en développement très actif et a tendance à péter à la figure. Des projets qui changent de nom, qui deviennent incompatible avec ta version de conan (Sur le slack de mon équipe, pendant un temps, mon pseudo était pip install conan --upgrade tellement on venait me voir pour ça).

Bon c'est globalement du passé bien que... certaines choses risquent de changer de nouveau mais surtout pour le meilleur.

**Anonyme20240202** · 06/03/2022, 12h36

Le seul truc qui me dérange avec Conan, c'est (au début en tout cas) qu'il poussait à mort la solution payante et sous entendait qu'il fallait que tu payes le serveur Conan chez eux si tu veux que ça fonctionne. Non pas que ça me dérange qu'on gagne sa vie mais l'usage était pas clair

Mais dernièrement, puis tiens là je viens de passer sur le site, je vois qu'ils ont l'air d'avoir complètement changé d'approche. Je retrouve même plus les offres payantes immédiatement sur leur site, ça pourrait enfin devenir la solution qui fait l'unanimité

**Cwningen** · 06/03/2022, 15h50

Je suis un vieux con, j'aime les gestionnaire de paquets des distributions Linux (ou msys2 pour Windows).

La seule fois où j'ai eu affaire à Conan (en tant qu'utilisateur), j'ai vraiment détesté. Je ne sais pas si c'était la faute de Conan ou du projet en question qui l'utilisait mal. Il téléchargeait et compilait des dépendances que j'avais déjà, et les installait dans mon home sans me demander mon avis. À un moment il était même incapable de les compiler parce que ma version de gcc était trop récente et il ne la connaissait pas. Et impossible de s'en passer. Installer les dépendances manuellement, ça peut être fastidieux, mais au moins c'est flexible.

**Anonyme20240202** · 06/03/2022, 17h20

Ouais tout à fait d'accord, je fais de même, mais du coup tu gères comment la grande question du "mes dépendances pour dev" vs. "les dépendances de mon système"

Genre ton système utilise une version donnée d'un soft, mais toi tu veux upgrade ou downgrade, par défaut ça va override l'existant sur ton système avec le package manager y'a pas de séparation.

Pour l'instant dans les endroits où je travaille, je force un peu les gens à toujours utiliser "latest" en gros, donc je force un peu tout le monde à s'aligner sur ce qui est à jour, et ça résout tous les problèmes. Quelque cas où y'a des breaks d'APIs mais rien de grave.

Parfois ça ronchonne parce que ça veut downgrade, mais c'est souvent par flemme de mettre à jour et rien de légitime (et ils sont criminellement pas à jour la majorité du temps, genre y'a des failles connus dans ce qu'ils utilisent).

Y'a tout de même de rares cas ou installer une dépendance va pas être compatible et là s'pas forcément simple à résoudre.

Y'a pas mal de gens qui proposent Docker pour résoudre ça mais je suis pas fan du tout, me parait absolument pas l'outil pour. Du coup je zieute du côté de NixOS mais je l'ai pas encore utilisé

**Cwningen** · 06/03/2022, 18h58

Tu installes dans des préfixes différents (genre /opt/<package> ou ~/opt/<package>). C'est facile d'ajouter des préfixes dans lesquels cmake va chercher ses dépendances. Tu peux les remplir avec des sources que tu as compilé toi-même ou avec des gestionnaire de paquets alternatifs (par exemple vcpkg). Le reproche que je fais à mon expérience avec conan, c'est surtout une trop forte intégration avec le script cmake qui empêche de le contourner quand ça déconne (ou que mes autres sources de paquets seraient plus pratiques).

Après ça dépend du contexte. Dans mon cas, je parlais de logiciel libre que n'importe qui peut vouloir compiler dans des environnements différents. Si on parle de logiciels internes à une entreprise, l'approche peut-être différente.

**Raplonu** · 07/03/2022, 02h02

Envoyé par Cwningen

La seule fois où j'ai eu affaire à Conan (en tant qu'utilisateur), j'ai vraiment détesté. Je ne sais pas si c'était la faute de Conan ou du projet en question qui l'utilisait mal. Il téléchargeait et compilait des dépendances que j'avais déjà, et les installait dans mon home sans me demander mon avis. À un moment il était même incapable de les compiler parce que ma version de gcc était trop récente et il ne la connaissait pas. Et impossible de s'en passer. Installer les dépendances manuellement, ça peut être fastidieux, mais au moins c'est flexible.

Conan fourni les binaires quand il les possède et recompile quand la config est manquante. Je trouve que c'est plutôt une bonne chose. On peut espérer qu'ils fourniront un plus grand panel de binaires à l'avenir. Concernant le compilo, ils sont listés dans settings.yml dans le répertoire conan. Tu peux y ajouter le tiens.

Aussi, tu peux lui dire où DL avec CONAN_USER_HOME.

Conan a beaucoup changé ces dernières années. Il est totalement sorti du cmake. Tu peux ainsi tout à fait enlever une dépendance de ton conanfile.txt et laisser cmake la trouver dans ton système. Mais ça reste limité. Par exemple, boost utilise zlib, impossible de lui dire d'utiliser zlib de ton système.
C'est en discussion mais ils ont pas l'air très préoccupé par ça pour le moment.

Bon par contre, je le défend mais son utilisation m'a pousser à en être un expert. Comme vous le montrez, même avec une utilisation simple, on se retrouve confronté a plein de problèmes contrairement à pip ou cargo. Un des points noirs pour moi est comme avec cmake, c'est pas claire pour un débutant pour savoir comment l'utiliser. Avec cmake, il faut utiliser quel générateur ? cmake, cmake_multi, cmake_paths, cmake_find_package, cmake_find_package_multi, CMakeToolchain ou CMakeDeps ? L'exemple qu'ils donnent dans la doc utilise le premier, cmake qui est clairement à éviter.

**Thamior** · 31/03/2022, 17h38

Bonjour à tous, je reviens avec une autre question C++. En gros j'ai un constructeur template variadique pour ma classe (qui est elle même templatée) :

Code:

template <class T>
class MaClasse
{
 template<class... Args, 
 MaClasse<T>(Args&&... args);
};

Jusqu'ici, ça marche, je tatonne un peu avec l'histoire du perfect forwarding (le "Args&&" qui n'est pas une rvalue reference, si j'ai bien compris).
Par contre, là ou ça commence à moins marcher c'est quand je veux construire un MaClasse<T> à partir d'un MaClasse<T>, donc quand j'appelle le constructeur de copie. En effet, la signature du constructeur de copie passe dans le template, donc il génère ça (qui ne fait pas du tout ce que je veux) au lieu du constructeur de copie.

Ma solution, que je trouve horrible, est d'utiliser enable_if pour empêcher l'utilisation du constructeur template quand je veux utiliser le constructeur de copie.

Code:

template <class T>
class MaClasse
{
 template<class... Args, 
 std::enable_if_t<!std::is_same<const MaClasse<T>&, Args...>::value, bool> = true,
 std::enable_if_t<!std::is_same<MaClasse<T>&, Args...>::value, bool> = true,
 std::enable_if_t<!std::is_same<MaClasse<T>&&, Args...>::value, bool> = true>
 MaClasse<T>(Args&&... args);
};

Alors ça marche, et il y a peut-être moyen d'exprimer ça avec un seul enable_if, mais ce que je me demande surtout c'est si c'est la façon "standard" de faire, parce que bon désolé mais

**Cwningen** · 31/03/2022, 18h32

Déjà il me semble que le constructeur c'est MaClasse et non MaClasse<T>, je suis étonné que ça marche.

Pour le problème de la référence universel qui te défini le constructeur de copie/move, la solution c'est ajouter un paramètre qui ne sert à rien :

Code:

class MaClasse
{
public:
    static inline constexpr struct tag_special_t {} tag_special = {};
    template<typename... Args>
    MaClasse(tag_special_t, Args &&... args) {
        // ...
    }
};

int main() {
    MaClasse mon_objet(MaClasse::tag_special, "plein de choses ici");
}

PS: Et aussi std::is_same<const MaClasse<T>&, Args...>, ça doit pas marcher quand le nombre de Args... est différent de 1.

Discussion: Le topic de la programmation: Et envoyez des sioux!

Outils de la discussion

Règles de messages