Installer SQLite3 avec CMAKE sous Windows 10

Version imprimable

11/10/2021, 00h18
NicolasRoyer

Installer SQLite3 avec CMAKE sous Windows 10

Bonjour,
Je suis débutant en développement avec CMAKE (mais pas avec C++) sous Windows 10, et je rencontre des difficultés à comprendre un peu le mécanisme.
Je souhaite en effet utiliser les libs de SQLite3, cependant je ne sais absolument pas comment l'installer.
Avec par exemple Boost en C++, j'ai pu l'installer avec un .exe, ce qui a permis à CMAKE GUI de le détecter facilement lorsque j'ai ajouté find_package(Boost 1.74.0 REQUIRED) dans le CMakeLists.txt du projet racine.
Seulement pour SQLite3 il n'y a pas de .exe pour lancer l'installation.

J'ai vu des posts qui disaient d'inscrire le chemin absolu dans le CMakeLists.txt de l'endroit où on allait mettre la lib SQLite, mais de ce que j'ai compris c'est contraire à la bonne pratique.

Merci à vous.
11/10/2021, 07h43
koala01
Salut,

A priori, si tu disposes d'une version "suffisamment récente" de CMake (supérieure ou égale à la version 3.14... la version actuelle étant la 3.21.3 :D), CMake devrait disposer directement des fichiers qui lui permettront de retrouver sqlite s'il est installé à un "endroit habituel" à l'aide de l'instruction "classique" find_package(sqlite3).

On peut donc considérer que le problème est virtuellement résolu du coté de CMake, pour autant que l'on s'arrange pour installer sqlite "au bon endroit".

Et le bon endroit, ce sera, en gros :
- les fichiers d'en-tête dans un sous dossier (nommé sqlite) du dossier include
- la bibliothèque dans le dossier lib
- l'exécutable et éventuellement la dll dans le dossier bin
Pour la suite, hé bien, cela va énormément dépendre de ta configuration personnelle, et, bien entendu, du compilateur (voire de l'EDI) que tu utilises...

Sauf erreur de ma part, sous VisualStudio, tu dois pouvoir trouver le moyen d'installer sqlite comme "module" et avoir la certitude que tout sera placé "au bon endroit".

Par contre, si tu utilise MinGW, il va falloir mouiller un peu la chemise, dans le sens où il faudra partir des sources pour l'obtenir et que , manque de bol, les sources la gestion du projet du coté linux (car le makefile destiné à l'usage de visual studio ne nous intéresse pas ici) n'utilise pas CMake, mais les autotools, qui ne sont utilisables sous windows qu'au travers de trucs comme msys.

Comme je ne sais pas dans quelle situation tu te trouves, je ne vais pas commencer à t'expliquer comment t'y prendre dans les différents cas, cela ferait une réponse beaucoup trop longue pour un bénéfice sommes toutes limité.

Par contre, si tu as besoin d'une aide plus précise, tu peux toujours venir la demander, en précisant cette fois quel compilateur, voir, quel EDI tu utilises généralement ;)
11/10/2021, 10h56
NicolasRoyer
Merci beaucoup pour ta réponse.

Alors concernant l'arborescence que j'utilise, je ne trouve pas d'information sur quelle est la "bonne" façon d'agencer le projet, donc j'ai procédé comme suit (que j'ai téléchargé sur le site sqlite):
- sqlite3
  - sdk
    
    include
    
    shell.c
    sqlite3.c
    sqlite3.h
    sqlite3ext.h
    
    lib
    
    sqlite3.def
    sqlite3.dll
  - sqldiff.exe
  - sqlite3.exe
  - sqlite3_analyzer.exe
J'ai mis ce dossier dans C:\ directement (je ne sais pas si c'est le bon endroit non plus).

J'utilise Visual Studio 2019 pour développer. Cependant de ce que j'ai compris, étant donné que CMAKE est destiné à avoir un code portable, j'évite absolument d'avoir de setter des configs à travers l'interface de Visual Studio. Si je dois setter des configs c'est soit à travers CMakeLists.txt, soit directement dans CMAKE GUI. J'ai vu des développeurs qui passaient directement dans les propriétés du projet dans Visual studio pour setter des Path de bibliothèques, mais honnêtement j'ai un doute sur la portabilité et la maintenance de cette manœuvre. C'est aussi la raison pour laquelle je n'installe pas sqlite3 via le gestionnaire de modules de visual studio (idem pour cmake, je génère via l'interface CMAKE GUI).
Par contre je build via visual studio une fois que tout est en place (clic droit > générer sur le projet).

Il y a beaucoup de choses que je ne comprends pas encore totalement, d'où peut être certains raisonnements qui peuvent être décousus :).
Est-ce que les explications semblent un peu plus claires? :)
11/10/2021, 14h40
foetus

Citation:

Envoyé par NicolasRoyer

C'est aussi la raison pour laquelle je n'installe pas sqlite3 via le gestionnaire de modules de visual studio (idem pour cmake, je génère via l'interface CMAKE GUI).

Pauvre bibliothèque SQLite3 :aie: :aie:

Je comprends que tu veuilles mettre cette bibliothèque dans "les chemins système" pour la partager entre les projets et ainsi la mettre à jour pour tous les projets en 1 seule fois.
Mais SQLite3 est très légère : tu mets les fichiers .c/ .h dans ton projet comme ton code (peut-être dans 1 dossier spécifique), c'est fini.
Il me semble que shell.c n'est pas utile (c'est pour faire 1 ligne de commandes) et sqlite3ext.h c'est pareil (sauf si tu as besoin de trucs spécifiques) : lis la documentation tu verras.

Pourquoi faire 1 module, 1 bibliothèque dynamique (c'est déjà fait sqlite3.dll) ou je ne sais pas quoi d'autre :?

D'ailleurs tu as 1 module CMake FindSQLite3 (<- lien officiel en anglais)
:whistle: je ne connais pas CMake donc je ne sais pas comment l'utiliser
11/10/2021, 16h00
koala01
Citation:
Envoyé par NicolasRoyer

Merci beaucoup pour ta réponse.

Alors concernant l'arborescence que j'utilise, je ne trouve pas d'information sur quelle est la "bonne" façon d'agencer le projet, donc j'ai procédé comme suit (que j'ai téléchargé sur le site sqlite):

sqlite3

sdk

include

shell.c
sqlite3.c
sqlite3.h
sqlite3ext.h

lib

sqlite3.def
sqlite3.dll

sqldiff.exe
sqlite3.exe
sqlite3_analyzer.exe

J'ai mis ce dossier dans C:\ directement (je ne sais pas si c'est le bon endroit non plus).
C'est pas mal comme organisation de projet (tu peux juste retirer le fichier shell.c qui n'est pas un fichier d'en-tête du dossier include

"Tout ce qu'il te reste à faire, alors, c'est d'indiquer (sans doute au travers de la variable SQLITE3_DIR à c:\sqlite3\sdk (tu pourrais aussi remonter tes dossier include et lib d'un cran (et adapter la variable en conséquence, bien sur) ;)

Citation:

J'utilise Visual Studio 2019 pour développer.

Oui, ben, justement: tu devrais, du coup, installer directement sql au travers de visual studio, qui se chargera normalement de gérer lui même ses spécificités se recherche pour CMake ;)

A priori, une fois que tu as installé la bibliothèque à l'aide du système de gestion des paquets de visual studio, il te suffira d'utiliser la commande find_package(sqlite3) pour que tout se fasse automatiquement. Ca ne sert à rien de se casser la tête pour faire plus compliqué que cela

(si tu te demande pourquoi je dis "a priori", c'est parce que c'est ce que j'ai en tête du fait de mes souvenirs avec visual studio, mais que je ne suis pas en mesure de le lancer pour l'instant pour confirmer mes dires ;) )

Citation:

Envoyé par foetus

Pauvre bibliothèque SQLite3 :aie: :aie:

Je comprends que tu veuilles mettre cette bibliothèque dans "les chemins système" pour la partager entre les projets et ainsi la mettre à jour pour tous les projets en 1 seule fois.
Mais SQLite3 est très légère : tu mets les fichiers .c/ .h dans ton projet comme ton code (peut-être dans 1 dossier spécifique), c'est fini.
Il me semble que shell.c n'est pas utile (c'est pour faire 1 ligne de commandes) et sqlite3ext.h c'est pareil (sauf si tu as besoin de trucs spécifiques) : lis la documentation tu verras.

Pourquoi faire 1 module, 1 bibliothèque dynamique (c'est déjà fait sqlite3.dll) ou je ne sais pas quoi d'autre :?

D'ailleurs tu as 1 module CMake FindSQLite3 (<- lien officiel en anglais)
:whistle: je ne connais pas CMake donc je ne sais pas comment l'utiliser

Oui, mais non...

On aurait, effectivement, pu se contenter de placer le code source de sqlite dans un sous dossier du projet, et la faire compiler automatiquement comme étant une partie de la solution... s'il avait été possible d'en configurer la compilation à l'aide de CMake.

Malheureusement, SQLite utilise encore les auto-tools (autoconf, automake, et tout et tout) pour la compilation sous linux et un simple makefile pour la compilation sous windows. Et elle a beau être "relativement légère (en fait, ils on amalgamé une centaine de fichiers sources en un seul grand fichier de ... 235 000 lignes, et un peu plus), il y a malgré tout pas mal d'options qui méritent d'être configurées (même pour une compilation "de base")

Il y a -- bien sur -- la possibilité de configurer sqlite à l'aide des autotools au travers de cmake, seulement... il faut que les autotools soient disponibles (ce qui signifie compiler sous MSYS, au mieux, ce qui n'est pas forcément une option)

On en vient donc relativement facilement à l'option qui consiste en la création d'un CMakeLists.txt basé sur les fichiers utilisés par autotools. Cependant, je doute fort que ce soit vraiment aisé pour quelqu'un qui a déjà des problèmes pour faire accepter par CMake le fait que sqlite est installé :P

J'ai bien trouvé un script python qui semble permettre d'automatiser le travail ==>ICI<== cependant, comme le projet n'a plus bougé depuis cinq ans, je ne peux pas garantir que nous ne nous retrouvions pas avec des trous qu'il faudrait combler pour que cela marche.

Bref, tout cela pour dire que je comprends l'envie du P.O de laisser CMake se débrouiller tout seul pour vérifier la présence de cette bibliothèque :D

1 pièce(s) jointe(s)

Merci beaucoup pour vos réponses.

Alors, j'ai compris quelques petites choses supplémentaires, je vais vous en faire part.
Donc je développe sous Windows 10, et j'ai donc installé CMAKE GUI.
J'ai aussi installé la bibliothèque Boost C++ à travers un fichier .exe.
J'ai ensuite créer un projet vide comme ceci (en gras ce sont les dossiers):

HelloWorld

build
CMakeLists.txt
main.cpp

Voici le contenu des fichiers:

CMakeLists.txt
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 cmake_minimum_required(VERSION "3.20.6") project("HelloWorld") add_executable("${PROJECT_NAME}" "main.cpp") install(TARGETS "${PROJECT_NAME}" DESTINATION bin) #${CMAKE_INSTALL_PREFIX}/bin install(FILES "main.cpp" DESTINATION src) #${CMAKE_INSTALL_PREFIX}/src # Get Boost Library find_package(Boost 1.74.0 REQUIRED COMPONENTS date_time filesystem iostreams) target_link_libraries("${PROJECT_NAME}" Boost::date_time Boost::filesystem Boost::iostreams) # Just some tests include(CTest) add_test("test1" "${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}") include (CPack)
Ensuite dans le fichier main.cpp:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 #include <boost/lambda/lambda.hpp> #include <iostream> #include <iterator> #include <algorithm> int main() { using namespace boost::lambda; typedef std::istream_iterator<int> in; std::for_each( in(std::cin), in(), std::cout << (_1 * 3) << " "); }
Il s'agit donc d'un code très simple pour le moment qui va utiliser la bibliothèque Boost pour multiplier par 3 les inputs.

Cependant, avant d'en arriver là, il faut lancer le soft CMAKE GUI pour pouvoir compiler générer le projet (donc ici HelloWorld).
Sur CMAKE GUI je définis le PATH du code SOURCE, puis le PATH pour les BINAIRES une fois compilés (donc ici HelloWorld/build).

Une fois qu'on a décidé des PATH, on va cliquer sur "Générer", ce qui va nous ouvrir une boite de dialogue afin de choisir sur quel IDE le projet sera généré.
Je choisis Visual Studio 2019 et je clique sur générer ensuite. Ca va me générer les fichiers .sln afin que je puisse commencer à développer/débugger etc... sous Visual Studio.
De plus l'interface CMAKE GUI m'indique toutes les variables CMAKE utilisées et qui sont apparues lorsqu'on a cliqué sur le bouton "Configure".

Pour rappel le bouton "Configure" va prendre le contenu de CMakeLists.txt et va tenter de trouver les librairies pour chaque ligne "find_package" afin de pouvoir les utiliser dans notre projet.

Donc là tout est bon, on a bien toutes nos libs bien placées avant de lancer Visual Studio, ce que je pense être une bonne pratique.

Ensuite c'est là où ca se gâte: étant donné qu'il n'y a pas de .exe pour sqlite qui permette de l'installer sous Windows, on a directement des fichiers .c, .h et des .exe (.exe qui ne sont pas des fichiers d'installation mais des des invites de commandes avec sqlite). Et lorsque j'utilise la commande dans CMakeLists.txt:

Code:

find_package (SQLite3 REQUIRED)

Lorsque je génère sous CMAKE GUI, j'ai le message d'erreur suivant:

Code:

Could NOT find SQLite3 (missing: SQLite3_INCLUDE_DIR SQLite3_LIBRARY)

Voici une capture d'écran de CMAKE GUI:
Pièce jointe 606422

Le problème est que:

Je ne connais pas l'emplacement par défaut de l'installation de cette lib sqlite.
Je ne peux pas inscrire le PATH dans le CMakeLists.txt car ce n'est pas une bonne pratique.
Je ne peux pas utiliser SQLite à travers Visual Studio car la lib doit être trouvée avant de lancer Visual Studio (étant donné que ça se fait lors de la génération sous CMAKE GUI) - Je sais je suis têtu :D.

Déjà une question que je me pose: est-ce que le projet peut contenir plusieurs fichier CMakeLists.txt? Si oui est-ce qu'il doit y en avoir un dans chaque sous dossier?

Sinon j'ai effectivement trouvé cette page pour findSQLite3 avec CMAKE:
https://cmake.org/cmake/help/latest/...ndSQLite3.html

Mais honnêtement je ne comprends absolument rien à son utilisation car il n'y a pas grand chose sur la page :).

En espérant avoir été assez clair dans mes interrogations? :)

Bon, j'aurai sué pour pouvoir te donner une réponse :P

Mais bon, cela valait le coup, parce que c'est un problème auquel on risque d'être régulièrement confronté ;)

D'abord, il faut savoir que l'installation de sqlite sous visual studio n'est pas aussi automatique que ce que je ne le croyais à la base, et il va donc déjà falloir "mouiller la chemise" pour avoir quelque chose de "correct".

La première chose à faire, ce sera de s'assurer de disposer de "tout ce qu'il faut" pour pouvoir utiliser sqlite, à savoir:

la dll pour l'exécution
le(s) fichiers d'en-tête pour la compilation
le fichier .lib (en ce qui concerne visual studio) ou le fichier .a (pour ce qui concerne MinGW / clang) pour l'édition de liens.

Le fait étant que si tu te rend sur la page de téléchargement, il n'y a aucun fichier qui te fournisse l'ensemble et que tu ne trouveras nulle part de fichier .lib ou .a :'(

on va donc commencer par télécharger la dll, qui est accessible au travers du fichier sqlite3-<version window>-<numero de version>.zip. Il est à noter que si <numero de version> va varier avec le temps (raison pour laquelle je n'en met pas de précis), <version de windows> devra correspondre à l'architecture pour laquelle tu veux générer ton exécutable, à savoir : win32-x84 pour une architecture "32 bits" ou win64-x84 pour une architecture 64 bits. Mais bon, tu t'en serais douté, je présume ;)

Il va bien sur falloir décompresser l'archive (qui contient une dll ainsi qu'un fichier .def) dans un dosier "facilement accessible" (dont le nom ne contienne -- de préférence -- pas d'espace). Par facilité, je considérerai que ce dossier correspond à sqlite_dir, de manière à rester aussi adaptable que possible :D

Une fois l'archive décompressée, il va falloir générer le fichier .lib dont on a besoin pour l'édition de liens. Et pour ce faire, on va lancer une ligne de commandes qui contiennent les variables d'environnement de visual studio. On la trouve, a priori, dans le menu démarrer ->dossier visual studio et porte le doux nom de <architecture > Tools command prompt for Visual Studio.

Encore une fois, il faut être attentif à choisir la version qui correspond à l'architecture cible et à la dll que l'on a téléchargé.

Dans cette ligne de commandes, on va "simplement" rentrer dans le dossier sqlite_dir, et introduire la commande

Code:

sqlit_dir> lib /DEF:".\sqlite3.def" /OUT:".\sqlite3.lib"

qui, au prix d'un avertissement nous signalant qu'il a sélectionné une cible par défaut, devrait nous générer le fichier .lib tant souhaité.

Il ne nous manque désormais plus que le(s) fichiers d'en-tête, que nous pourrons nous procurrer en téléchargeant l'archive nommée sqlite-amalgamation-<numero de version>.zip.

Pour le coup, le seul fichier qui nous intéresse sera sqlite3.h et, si tu en as besoin, sqlite3ext.h, que l'on va -- bien gentiment -- décompresser dans notre dossier sqlite_dir.

Oufff!!!! on a désormais ce qu'il faut pour travailler... Il ne reste donc "plus qu'à" faire en sorte que CMake aille chercher après sqlite dans ce fameux dossier sqlit_dir.

Et, ca, en fait, c'est "assez facile", car il "suffit" d'ajouter le dossier sqlite_dir à la variable CMAKE_PREFIX_PATH avec une instruction proche de list(APPEND CMAKE_PREFIX_PATH "valeur_réelle_de_sqlitedir").

Une fois cette instruction placée dans le CMakeLists.txt, nous pourrons lui demander de rechercher sqlite en rajoutant à la suite la commande find_package(SQLite3 REQUIRED) et veiller à ce que notre projet utilise sqlite grâce aux habituelles commande target_include_directories et target_link_libraries, ce qui nous donnera quelque chose ressemblant à
Code:

1 2 3 4 5 6 7 find_package(SQLite3 REQUIRED) add_executable(leTest main.cpp) target_include_directories(leTest PUBLIC ${SQLite3_INCLUDE_DIRS}) target_link_libraries(leTest PUBLIC ${SQLite3_LIBRARIES})
(pour un projet tout simple composé du seul fichier main.cpp ;) )

Après, on peut vouloir chipoter un peu pour rendre ce fichier plus compatible avec les différents systèmes, car la procédure que j'indique ici est essentiellement valable avec viusal studio (on devrait pouvoir faire pareil avec les outils de MinGW, note ;) ) et parce que je doute que l'on trouve, sous linux, un dossier dont le nom commence par C: ou E: :P

On peut d'ailleurs aussi envisager le fait que l'installation de sqlite telle qu'elle a été décrite ici n'a pas forcément été faite dans le même dossier partout, et donc, demander à celui qui veut compiler le projet de préciser le dossier où cmake pourra aller chercher les fichiers dont il a besoin.

La fameuse commande list(APPEND CMAKE_PREFIX_PATH "valeur_réelle_de_sqlitedir") pourrait donc se transformer en quelque chose comme
Code:

1 2 3 4 5 6 7 8 9 10 11 # nous n'aurons a priori des problèmes pour retrouver # sqlite que sous windows if(WIN32) # je m'attend à ce que l'utilisateur définisse la variable SQLITE_DIR # et j'envoie un message bloquant si ce n'est pas le cas if(NOT SQLITE_DIR) message(ERROR "Please define the SQLITE_DIR assqlite installation path") return endif() list(APPEND CMAKE_PREFIX_PATH ${SQLITE_DIR}) endif()
Et, du coup, lorsque l'utilisateur invoquera la commande cmake pour lancer la configuration, il faudra qu'il introduise quelque chose comme

Code:

cmake <...> -DSQLITE_DIR=<dossier d'installation de sqlite>

Merci beaucoup pour ta réponse! Tu as pris le temps d'expliquer tout ca c'est vraiment super!
Je sens qu'on se rapproche du but, j'ai réussi à faire détecter du coup la library par CMAKE avec ces commandes (c'est la commande list qui a fait fonctionné le programme).

Seulement je suis confronté à un problème qui n'apparait pour que le coup que sous Windows.
CMAKE fonctionne et le code compile, cependant il est incapable de trouver le fichier sqlite3.dll. Qui est pourtant au même emplacement que tous les autres fichiers .c, .h, etc...
Voici mon arborescence:

HelloWorld

apps

main.cpp

build
include
sqlite3

sqlite3.h
sqlite3ext.h
sqlite3.exp (generated)
sqlite3.dll (could also be generated by the cmd line "cl sqlite3.c -link -dll -out:sqlite3.dll")
sqlite3.def
sqlite3.lib (generated)
sqlite3.c
shell.c

src
CMakeLists.txt

Je me demande si je ne devrais pas mettre un fichier CMakeLists.txt dans le dossier sqlite3? Je ne sais justement pas à quel moment je dois insérer un nouveau fichier CMakeLists.txt dans un nouveau dossier.

Et le contenu de mon CMakeLists.txt:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 # Basic information of the project cmake_minimum_required(VERSION "3.20.6") project("HelloWorld") add_executable("${PROJECT_NAME}" "apps/main.cpp") # Include directories include_directories(include) include_directories(src) include_directories(apps) # Define where to export the program install(TARGETS "${PROJECT_NAME}" DESTINATION bin) #${CMAKE_INSTALL_PREFIX}/bin install(FILES "main.cpp" DESTINATION src) #${CMAKE_INSTALL_PREFIX}/src # Get Boost Library find_package(Boost 1.74.0 REQUIRED COMPONENTS date_time filesystem iostreams) # Include CTest and a simple Test include(CTest) add_test("test1" "${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}") # Include CPack include (CPack) # Include SQLite3 list(APPEND CMAKE_PREFIX_PATH "sqlite3") find_package (SQLite3 REQUIRED) target_include_directories(${PROJECT_NAME} PUBLIC ${SQLite3_INCLUDE_DIRS}) target_link_directories(${PROJECT_NAME} PUBLIC ${SQLite3_LIBRARIES}) include_directories(${SQLite3_INCLUDE_DIRS}) target_link_libraries("${PROJECT_NAME}" Boost::date_time Boost::filesystem Boost::iostreams ${SQLite3_LIBRARIES})

14/10/2021, 02h20
koala01

En fait, dans l'idéal, il faudrait copier la dll dans le dossier dans lequel se trouvera l'exécutable final et ce, principalement, lors du packaging / de l'installation.

Pour t'éviter d'avoir ** trop ** de problèmes lors des tests et de la compilation, tu peux aussi "tout simplement" ajouter le dossier dans lequel se trouvent tous les fichiers de sqlite à ta variable PATH, mais cela ne résoudra pas le problème du packaging / de l'installation (surtout si l'installation se fait sur un pc différent de celui sur lequel la variable PATH a été modifiée) :P

Pour modifier la variable PATH, tu as trois solutions:
1- passer par le panneau de configuration -> système->"A propos de" ->paramètres avancés du système -> dans l'onglet "Paramètres système avancés, cliquer sur "variables d'environnement"->modifier la variable PATH

2- Dans une invite de commande (qui te servira à lancer l'exécutable), introduire la commande

Code:

set PATH=%PATH%;<dossier_sqlite>

mais l'information sera perdue à chaque fois que tu fermera la fenêtre

3- ajouter la même commande qu'en (2) dans les fichiers *.bat (ou du moins celui qui correspond à l'architecture cible pour laquelle tu a la dll) qui lance la commande avec les variables d'environnement de visual studio (typiquement, les fichiers se trouvent dans "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build" .

A priori, il devrait être possible avec CMake de copier la dll dans le dossier de compilation, pour peu que l'on connaisse le chemin d'accès utilisé.

Il se fait que ce chemin d'accès correspond .. le monde est bien fait, n'est-ce pas :question:à la variable SQLite3_INCLUDE_DIR, et comme le nom de la dll est lui aussi connu (sqlite3.dll) une commande proche de

Code:

file(COPY ${SQLite3_INCLUDE_DIR} DESTINATION ${CMAKE_CURRENT_BINARY_DIR}/sqlite3.dll)

devrait faire l'affaire pour l'exécution tout en étant plus propre que les solutions visant à modifier la variable PATH.

En jouant avec les commandes install, on devrait pouvoir s'en sortir ;)
15/10/2021, 00h29
NicolasRoyer

Merci beaucoup vraiment pour ton aide. Mais pour le moment je ne suis pas parvenu à utiliser sqlite.
J'ai réussi à un moment à ce qu'il trouve la library, mais un message d'erreur de lancement m'empêchait son utilisation.

Du coup j'ai lancé une VM sous Ubuntu et je vais commencer à coder dessus directement, comme ça je m'affranchis des .dll qui rajoutent une couche de complexité (j'y passais mes nuits).

Est-ce que tu saurais du coup, comment l'utiliser sous Linux cette library sqlite (je désespère complètement, je ne comprends pas pourquoi c'est aussi galère et aussi peu documenté)?

Bon, on va tout reprendre depuis le début, si tu veux bien, ce sera plus facile ;)

Mon objectif de base

Dans un premier temps, tout ce que je veux arriver à faire, c'est de compiler ceci ;
main.cpp
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 #include <iostream> #include <stdexcept> #include <string> #include <sqlite3.h> class SqlDb { public: SqlDb(std::string const& filename) : filename_{ filename } { int result = sqlite3_open(filename_.c_str(), &db_); if (result) { std::string error("impossible d'ouvrir la base de donnée "); error.append(filename_) .append(": ") .append(sqlite3_errmsg(db_)); throw std::runtime_error(error); } } SqlDb(SqlDb const&) = delete; SqlDb& operator = (SqlDb const&) = delete; ~SqlDb() { sqlite3_close(db_); } std::string const& filename() const { return filename_; } private: std::string filename_; sqlite3 * db_; }; int main(int argc, char* argv[]) { try { SqlDb db("Test"); std::cout << db.filename() << " has correctly been opend\n"; } catch (std::runtime_error e) { std::cout << e.what(); throw; } return 0; }
Et je parle bien juste de compiler ce code et de générer l'exécutable.

Je ne veux pas encore pouvoir l'exécuter, je ne veux pas encore pouvoir l'installer, je ne veux pas encore pouvoir le packager (pour le filer à mon voisin). Je veux juste mener la compilation et l'édition des liens à leurs termes.

Utiliser CMake
Pour ce faire, je vais utiliser CMake, et j'aurai donc un fichier CMakeLists.txt qui, dans sa plus simple expression ressemble à ceci:

CMakeLists.txt
Code:

1 2 3 4 5 6 7 8 9 10 11 cmake_minimum_required(VERSION 3.14) project(test VERSION 1.0.0.0 LANGUAGES CXX) find_package(SQLite3 REQUIRED) add_executable(leTest main.cpp) target_include_directories(leTest PUBLIC ${SQLite3_INCLUDE_DIRS}) target_link_libraries(leTest PUBLIC ${SQLite3_LIBRARIES})
Tu remarques que, une fois que j'ai indiqué la version minimale de CMake (la 3.14, qui est la version qui fournit le script de recherche de sqlite), je ne fais pas grand chose de compliqué:

je défini les informations de mon projet (nom, version et langages utilisés)
je m'assure de la présence de sqlite
je crée l'exécutable à partir de mon fichier main.cpp
j'ajoute le dossier dans lequel devrait se trouver le fichier sqlite3.h à la liste des dossier contenant des fichiers d'en-tête
j'ajoute la bibliothèque sqlite3 à la liste des bibliothèques devant être utilisées pour l'édition de liens.

Sommes toutes, rien de plus "classique" ;)

le projet de base
Mon projet de base se trouve donc dans un dossier spécifique (que je vais appeler ROOT_DIR par facilité) dont le contenu va ressembler à ceci:
Code:

1 2 3 ROOT_DIR |- CMakeLists.txt |- main.cpp
Installation de sqlite

Evidemment, si sqlite n'est pas installé sur mon système, je vais avoir quelques soucis pour compiler ce code pourtant très simple : le compilateur va m'envoyer paitre parce qu'il ne trouve pas le fichiers sqlite3.h et l'éditeur de liens (qui ne sera jamais lancé) m'enverrait paître parce qu'il ne trouve pas la bibliothèque :P

Sous linux (et debian like, comme ubuntu), une simple commande

Code:

apt-cache search sqlite | grep dev

devrait te permettre de trouver le paquet qu'il faut installer (libsqlite3-dev ou quelque chose comme cela).

Il devrait donc suffir d'une simple commande

Code:

sudo apt install libsqlite3-dev

pour que l'installation se fasse

Sous windows, il a fallu mouiller la chemise pour arriver à l'installer (cf mes explications précédentes). Nous devrons donc prévoir le cas où sqlite ne serait pas installé à un endroit "habituel", ce qui nous incitera à modifier le CMakeLists.txt pour lui donner la forme de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 cmake_minimum_required(VERSION 3.14) project(test VERSION 1.0.0.0 LANGUAGES CXX) # sous windows uniquement if(WIN32) # nous voulons que le développeur indique explicitement # quel dossier contient les fichiers de sqlite à l'aide de la # variable SQLITE_DIR (option -DSQLITE_DIR=la_ou_vit_sqlite if(! SQLITE_DIR) # si cette variable n'est pas définie, on l'engueule et son s'arrête message(ERROR "Please define the SQLITE_DIR variable") return endif() # si on arrive ici, SQLITE_DIR est définie, et on peut donc rajouter le dossier # à la liste des dossiers de recherche de CMake list(APPEND CMAKE_PREFIX_PATH ${SQLITE_DIR}) endif() find_package(SQLite3 REQUIRED) add_executable(leTest main.cpp) target_include_directories(leTest PUBLIC ${SQLite3_INCLUDE_DIRS}) target_link_libraries(leTest PUBLIC ${SQLite3_LIBRARIES})
Arrivés à ce stade, notre programme devrait déjà pouvoir compiler et l'édition des liens devrait pouvoir se faire, aussi bien sous linux que sous windows.

Sous linux, une fois le programme compiler, il devrait d'ailleurs s'exécuter correctement. Sous windows, nous aurons peut-être quelques problèmes du fait que la dll sqlite3.dll se trouve, pour l'instant, dans un dossier qui n'est pas utilisé pour la recherche des dll, et donc, l'exécution risque de planter avec un lamentable "impossible de trouver sqlite3.dll" :P

L'étape suivante sera donc de faire en sorte que cette p...n de dll se trouve dans le dossier "qui va bien". Et le plus simple est -- selon toute vraisemblance -- de placere une copie de la dll à coté de l'exécutable qui est généré.

NOTA:
Quand on compile avec visual studio, la compilation s'effectue dans un dossier créé automatiquement au niveau du projet et appelé out/build/<arch-Debug|Release> ce qui nous donnera au final une arborescence proche de
Code:

1 2 3 4 5 6 7 8 9 10 <ROOT_DIR> |->.vs #contient des fichiers spécifiques à visual studio (dossier) |-> Out | |->build | | |->x64-Debug # compilation en mode Debug (dossier) | | |->x64-Release # compilation en mode Release (dossier) | | |-> (d'autres dossiers pourraient arriver ici) |-> CMakeLists.txt |-> CMakeSettings.json # ajouté par visual studio |-> main.cpp
Mais bon, on s'en fout, parce que les dossier x64-Debug et x64-Release correspondent tous les deux au dossier de compilation, en fonction de si on compile en debug ou en release (ou sous une autre forme)

La solution au problème
A priori, la seule chose qu'il faille faire pour pouvoir tester notre programme lors du développement, c'est donc de copier la dll dans le dossier requis. Mais, évidemment, cela n'a de sens que sous windows (la bibliothèque partagée est bien à sa place sous linux ;) ).

Tout ce qu'il devrait falloir faire pour obtenir le résultat souhaité, c'est donc de modifier une fois encore notre CMakeLists.txt pour lui donner une forme proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 cmake_minimum_required(VERSION 3.14) project(test VERSION 1.0.0.0 LANGUAGES CXX) # sous windows uniquement if(WIN32) # nous voulons que le développeur indique explicitement # quel dossier contient les fichiers de sqlite à l'aide de la # variable SQLITE_DIR (option -DSQLITE_DIR=la_ou_vit_sqlite if(! SQLITE_DIR) # si cette variable n'est pas définie, on l'engueule et son s'arrête message(ERROR "Please define the SQLITE_DIR variable") return endif() # si on arrive ici, SQLITE_DIR est définie, et on peut donc rajouter le dossier # à la liste des dossiers de recherche de CMake list(APPEND CMAKE_PREFIX_PATH ${SQLITE_DIR}) # on copie la dll dans le dossier de compilation file(COPY ${SQLITE_DIR}/sqlite3.dll ${CMAKE_CURRENT_BUILD_DIR}/sqlite3.dll endif() find_package(SQLite3 REQUIRED) add_executable(leTest main.cpp) target_include_directories(leTest PUBLIC ${SQLite3_INCLUDE_DIRS}) target_link_libraries(leTest PUBLIC ${SQLite3_LIBRARIES})
Et, sauf erreur de ma part, tu pourras désormais utiliser le programme qui sera généré à partir du dossier dans lequel il aura été généré ;)

La suite, ce sera de faire en sorte que ton programme et la dll soient correctement packagés et installés (chez le voisin)... Mais ca, ce sera pour demain ;)

EDIT: si tu parles un peu anglais, tu peux aussi aller voir =>Cette discussion <= (sur stackovervlow) qui remonte à il y a longtemps, mais qui reste d'actualité par rapport à notre problème présent ;)