Langue C
  1. Langue C
  3. Paquet R qui relie à la bibliothèque C externe
Intereting Posts
Comment écrire des bits simples dans un fichier en C Requête sur un appel système sélectionné Pourquoi le nom du personnage peut contenir plus d’un caractère? Utiliser le pointeur vide sur un tableau memcpy causant ‘exc mauvais access’ Comment comstackr un exemple basique D-Bus / glib? C – Exception lors de l’utilisation de _int16 La fonction getlogin () c renvoie la valeur NULL et le message d’erreur “Aucun fichier ni répertoire” Est-ce que gmock peut être utilisé pour modifier des fonctions C? pourquoi ne puis-je pas utiliser l’initialisation partielle de la structure pour une structure malloced en C changer la casse: erreur: l’étiquette de la casse ne se réduit pas à une constante entière Erreur inattendue dans la liste double liée en C Passer le fichier en argument de ligne de commande realloc () ancienne taille invalide en utilisant “push” et “pop” dans une stack

Paquet R qui relie à la bibliothèque C externe

J’ai un code c qui utilise la bibliothèque igraph . Je voudrais mettre un wrapper R autour de lui et l’envoyer à CRAN sous forme de package R.

igraph ayant déjà un port R sur CRAN, il serait donc logique que mon paquet R ‘foo’ dépende de R igraph. Puisque foo utilise son propre code C qui dépend de C igraph, comment puis-je lier mes fonctions C à la bibliothèque igraph originale? J’ai lu que cela se fait dans un fichier appelé Makevars, mais que le lien vers une bibliothèque externe est très poilu.

Si ce n’est pas possible, vaut-il mieux simplement copier le code source igraph entier et le placer dans mon répertoire / src? Le paquet R igraph contient déjà un fichier appelé Makevars, mais je ne comprends pas comment tous les fichiers c sont construits – normalement, dans mon Makefile, j’ai quelque chose comme gcc (une liste de fichiers source .c) -o, mais Makevar ne contient que 

PKG_CFLAGS=-DUSING_R -I. -Ics -Iglpk -Iglpk/amd -Iglpk/colamd \ -g -O2 -I/usr/include/libxml2 -g -O2 -I/usr/include/libxml2 -DNDEBUG \ -DPACKAGE_VERSION=\"0.6\" -DINTERNAL_ARPACK \ -DIGRAPH_THREAD_LOCAL=/**/ PKG_CXXFLAGS= -DUSING_R -DIGRAPH_THREAD_LOCAL=/**/ -DNDEBUG PKG_LIBS=-lxml2 -lz -lpthread -licucore -lm -lgmp $(FLIBS) $(LAPACK_LIBS) $(BLAS_LIBS) all: $(SHLIB)

et il n’y a pas d’autre Makefile. En résumé, comment puis-je mettre du code C dans un paquet R qui dépend d’une autre bibliothèque C, et comment puis-je écrire les Makevars (ou Makefile) correspondants pour incorporer les fonctions C?

Une question plus ancienne a été postée ici, mais elle ne semble constituer qu’un lien pour vous aider à écrire votre propre code C qui ne dépend de rien.

Il y a plusieurs questions ici:

  1. Un paquet ‘foo’ peut-il être lié de manière fiable à un paquet ‘bar’? “Writing R Extensions”, au début de la section 5.8, sur “Liaison à d’autres packages” dit “non, pas généralement”, comme Gabor l’avait laissé entendre dans son commentaire précédent.

  2. Le code source C peut-il être mis dans un paquet pour construire un paquet qui dépend d’une autre bibliothèque: Oui, bien sûr, et beaucoup de paquets sur CRAN le font. Choisissez, par exemple, un exemple de package dépendant du GSL, des bibliothèques graphiques JPEG / TIFF, XML, ou … Vous pouvez étudier ces sources. Ce n’est pas facile, mais si vous étudiez ces packages, la documentation de Writing R Extensions et les autres réponses aux questions connexes, vous devriez vous y rendre.

Je prends une lecture légèrement différente de “Writing R Extensions”. Le paragraphe 1 de la section 5.8.1 (traitant des systèmes d’exploitation de type Unix) indique qu’il est possible mais non portable ou recommandé de se connecter à une bibliothèque partagée . Le paragraphe 2 indique que les bibliothèques statiques sont correctes (le “Ceci” en tête du paragraphe est source de confusion; à quoi cela fait-il référence?) Car la bibliothèque statique fournie par packA peut être découverte par packB lorsque packB est installé, puis incorporée à La librairie dynamic. Cela nécessite que packA fournisse une bibliothèque statique et est donc conscient que son rôle était de le faire. de nombreux packages penseront plutôt que leur rôle consiste à fournir une interface R à un sous-ensemble des fonctionnalités de la bibliothèque qu’ils encapsulent et à fournir un object partagé qui relie à la bibliothèque partagée dans son propre package.

Un exemple est le paquetage Rsamtools dans Bioconductor, qui crée des versions statiques de la bibliothèque samtools et fournit un mécanisme (difficile à obtenir par la droite) pour les paquets voulant accéder à la bibliothèque statique (une vignette fournit une vue des paquets dépendants). Il est important de fournir le chemin absolu à la bibliothèque statique PKG_LIBS="-l$(PKGB_PATH)/libpackB.a" pour éviter les liens statiques vers la même bibliothèque fournie par le système (avec les en-têtes fournis par packA).

@DirkEddelbuettel s’est presque sûrement engagé dans cette voie et signalera mes erreurs. Je suis d’accord avec son commentaire ci-dessous selon lequel l’utilisation d’une bibliothèque statique est sous-optimale (principalement du sharepoint vue de la consommation de mémoire?), Mais évitez les raisons de portabilité évoquées au paragraphe 5.8.1.