J'ai un petit problème, voilà le contexte:
Pour un projet, une librairie programmée en C++ qui permet de manipuler et faire pas mal de trucs avec des programmes linéaires, on a décidé de faire une interface pour Python pour que cette lib soit bien sympatique a utiliser.
J'utilise Boost.Python pour "faciliter" la création de cette interface.
Je crée la librairie dynamique (.so) qui est directement importable depuis un interpreteur python, tout se passe tres bien etc.
Mon probleme est que je veux que cette librairie soit utilisable par une personne n'ayant ni libpython, ni libboost etc. sans tous les liens vers les librairies dynamiques utilisées. Donc si quelqu'un avait une idée de comment faire cette librairie...
(Outils: g++ 3.3.4 / libboost1.32)
nitro Le 04/02/2005 à 20:47 Tu peux faire une bibliothèque principale, qui contient juste tes outils de manipulation de programmes linéaires, et rien d'autre. Celle-ci est utilisable à partir d'un programme C++. Puis une autre bibliothèque qui va faire le wrapper (qui sera donc liée à libpython et libboost) en utilisant la première bibliothèque.
So much code to write, so little time.
C'est deja ce que je fais en fait.
Mais pour utiliser la librairie en python, il faut quand même avoir libboost etc. et c'est cette librairie que je veux dégager de toute dépendance dynamique
nitro Le 04/02/2005 à 20:54 Si c'est déjà ce que tu fais alors je vois pas le problème... tu utilises lib1 qui n'a pas de dépendance quand tu fais du C++, tu utilises lib2 (qui dépend de lib1, libboost etc..) quand tu fais du python.
Sinon tu peux complètement te passer de Boost.Python en utilisant Swig.
So much code to write, so little time.
Le probleme c'est que lib2 devrait etre portable et utilisable (donc avec Python) par toute personne, n'ayant pas forcément Boost d'installé.
Il faut donc que je la libère de sa dépendance de Boost...
Enfiat, je pensais a quelque chose comme un g++ -static mais pour un .so
Je ne peux pas utiliser SWIG car il gère vraiment mal le C++, enfait, il est fait pour le C lui. C'est d'ailleurs pour cela que je suis passé à Boost.Python
"SWIG provides wrapping support for almost all of ANSI C++."
Quel est le problème avec cette lib exactement ?
Le premier exemple tiré de mon projet que j'ai essayé de passer sous SWIG n'a pas marché a cause d'une surcharge...
Avec Boost.Python, ca marche tres bien.
Ben t'as lu la doc sur comment on dit à swig qu'il doit gérer les surcharges ? Parce que ça marche nickel depuis que c'est supporté (et ça commence à faire un moment déjà).
Je dis pas que boost python c'est mal, hein, je m'en suis déjà servi sans problème particulier. Mais je suis passé à swig parce que c'est quand même beaucoup plus pratique à utiliser et rapide à écrire.
Y'a aussi un autre point qui rentre en compte
Comme on génére des programmes linéaires qui peuvent etre assez grand (500000 variables par exemple) il fuat que la manipulation soit bien rapide. Boost.Python offre une code plus rapide que SWIG
.
