[LINUX] Présentation de la configuration de la bibliothèque personnalisée

J'ai introduit configure il y a longtemps, mais j'ai oublié comment le faire. Je vais l'ajouter au code github, essayons donc de le configurer!

Qu'est-ce que configurer?

Chaque fois que j'écris un Makefile par moi-même, je change le chemin de la bibliothèque et le lien en fonction de l'environnement et je recherche le chemin de l'en-tête. Et ** La maintenance est difficile pour chaque environnement. ** ** ** → configure ** résout ce problème

Si vous définissez correctement configure, tout cela sera résolu sans autorisation.

C'est une explication courante.

Les caractéristiques et les impressions que je pense sont résumées en 3 lignes ci-dessous.

J'ai écrit diverses choses à la fin.

Procédure de base

  1. Installez les packages requis (auraient dû être autotool, libtool)
  2. Exécutez l'autoscan dans le répertoire supérieur de votre code
  3. configure.scan peut être fait, alors renommez-le en configure.ac
  4. Exécutez autoreconf --install * 1
  5. Ajoutez Makefile.am
  6. Exécutez automake (automake - add-missing uniquement au début)
  7. Corrigez configure.ac et Makefile.am pour l'erreur qui apparaît.
  8. Répétez les étapes 4 à 7 pour corriger l'erreur lors de l'exécution de la commande.

Ensuite, lorsque l'erreur disparaît et que ./configure → make peut être fait, il est terminé.

La procédure est fixe, mais je me demande s'il est difficile d'accéder à configure.ac et Makefile.am. Makefile.am et configure.ac doivent être basés sur le code existant et OSS.

Je décrirai ce que j'ai fait après le suivant.

À propos de Makefile.am

En gros, ça ressemble à ça

--Placer Makefile.am avec SUBDIRS dans un dossier sans src --Spécifiez le nom cible du dossier src → Le nom cible _XXXX devient la définition de l'indicateur du Makefile commun.

Exemple

```Makefile.am`


SUBDIRS = lib include

```lib:Makefile.am:lib`


# si vous n'avez pas besoin d'installer
noinst_LTLIBRARIES = libtimelog.la
# Lors de l'installation
lib_LTLIBRARIES = libtimelog.la

# Spécification du code
libtimelog_la_SOURCES = timetestlog.c

Vous pouvez choisir d'installer également les en-têtes et les binaires. Si vous ne l'installez pas, il est courant de ne pas le faire.

``Makefile.am`


# Lors de l'installation
include_HEADERS= libtimelog.la

# Lors de l'installation
bin_PROGRAMS = test

Il semble qu'il y ait diverses bizarreries dans la méthode de description ici, il est donc nécessaire d'enquêter si nécessaire.

De plus, il semble qu'il soit possible d'élaborer une définition commune comme celle-ci

```am.conf`


common header deifinition
# Mettez ce fichier sur le dessus
AM_CPPFLAGS=-I$(top_srcdir)/include
INCLUDES_PATH=$(top_srcdir)/include

Makefile.suis côté


# Charger ce paramètre avec include
include $(top_srcdir)/am.conf

Je me souviens d'avoir fait à la fois dynamique et statique, mais c'est une autre opportunité.

2018/05/15

Comment rendre à la fois dynamique et statique: il semble bon d'ajouter LDFLAGS. Par exemple, c'est OK si vous ne passez que rpath comme suit. Si ** -shared ou -static est attaché, l'un d'entre eux sera prioritaire, il semble donc que l'intérêt soit de ne pas attacher non plus **. Opération confirmée sur Ubuntu 18.04

```lib:Makefile.am:lib`


libtimelog_la_SOURCES = timetestlog.c
libtimelog_la_LDFLAGS=-rpath $(libdir)

À propos de configure.ac

Quant à quoi faire -Ajouter la description de XXX / Makefile à AC_CONFIG_FILES pour tous les dossiers à compiler. -Ajoutez les options nécessaires qui n'apparaissaient pas dans l'autoscan.

Dans ce dernier cas, une erreur se produira lors de l'automake et de l'autoreconf, vous pouvez donc les écraser un par un, mais cela semble difficile si vous n'êtes pas habitué à cela.

Je suis tombé sur ce qui suit

・ L'erreur suivante se produit pendant l'automate salé

error: no proper invocation of AM_INIT_AUTOMAKE was found.

→ Ajoutez ce qui suit à configure.ac pour gérer

```configure.am`


AM_INIT_AUTOMAKE([foreign -Wall -Werror])
AM_PROG_AR

-L'erreur suivante pour le dossier lib dans autoreconf

libtoolize: Consider adding AC_CONFIG_MACRO_DIR([m4])' to configure.ac and libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree. libtoolize: Consider adding -I m4' to ACLOCAL_AMFLAGS in Makefile.am.

→ Ajoutez ce qui suit à configure.ac pour gérer

```configure.am`


LT_INIT

Maintenant, je travaille très bien.

Par exemple, une bibliothèque telle que pthread la détectera pendant l'autoscan et l'ajoutera et la liera à configure.ac sans autorisation. Il est donc facile de ne connaître que la bibliothèque que vous avez créée.

La seule fonctionnalité utile dont je me souviens

Vous pouvez créer vos propres options ./configure. (Et vous pouvez également le vérifier correctement avec ./configure --help. Personnellement, j'ai été impressionné)

Par exemple, si vous voulez activer / désactiver le débogage avec --enable-debug, utilisez ʻAC_ARG_ENABLE`` et ʻAC_DEFINE``.

AC_ARG_ENABLE reconnaît l'option d'activation. AC_ARG_ENABLE (option, message d'aide, shell d'exécution lorsque l'option est spécifiée, valeur par défaut)

AC_DEFINE passera une définition comme -DXXX AC_DEFINE (définir le nom, définir la valeur, [description])

C'est comme ressentir.

J'ai ajouté l'option treadsafe comme celle-ci.

```configure.am`


#AC_ARG_ENABLE( option, help message, script code for this option, default value)
AC_ARG_ENABLE(threadsafe,
[  --enable-threadsafe      enable to share handle between threads [[default=no]]],
[\
#
case "${enableval}" in
 yes) enable_threadsafe=yes ;;
 *)   AC_MSG_ERROR(bad value for --enable-) ;;
esac],
enable_threadsahe=no)

#check flag and set defile
if test x"${enable_threadsafe}" = x"yes"; then
  AC_DEFINE(THREAD_SAFE, 1, [Define to 1 if you want to ensure thread safe])
else
echo "libnotify is disabled"
fi

L'aide ressemble à ceci.

./configure --help
...
  --enable-threadsafe      enable to share handle between threads [default=no]

Ça devient comme ça tout de suite! C'est également pratique car il est facile de gérer les options de débogage.

J'ai fait un résumé des options. C'est ici.

Impression personnelle

bon point

――Il est vraiment facile de lier la bibliothèque standard sans permission (j'oublie d'ajouter rt ou quelque chose avec une probabilité élevée) ――Je suis heureux que vous puissiez le faire avec quelques descriptions

C'est un passe-temps personnel, mais je pense que cela vaut la peine d'être présenté même à la fin. L'option de compilation est pratique, mais elle est difficile à partager car elle donne un avant-goût au créateur. J'oublie même si je le fais moi-même. Cela peut être confirmé avec ./configure --help sans ** maintenance de la documentation. ** ** Les gens qui aiment l'implémentation n'écrivent pas de documentation, mais quand il s'agit d'écrire de l'aide ou de l'utilisation, ils l'écrivent correctement.

Points à craindre

――Il est difficile de suivre l'erreur dans la partie qui vous a été laissée au moment de l'introduction

Comme pour tous les outils, il est difficile d'enquêter sur la cause lorsque quelque chose qui ne comprend pas ce qu'il contient ne fonctionne pas. Quand j'ai essayé d'introduire diverses choses sérieusement dans l'ancien temps, j'ai fait beaucoup de débogage dans le script de configuration, Je me souviens avoir eu beaucoup de mal à trouver la cause.

Il y a un journal dans config.log, donc si vous avez un bon OSS, cela seul sera un tremplin pour en trouver la cause. Si vous le faites vous-même, vous douterez de beaucoup de choses.

--Je ne comprends pas le comportement quand il y a une différence de version dans libtool.

Je ne suis pas vraiment sûr de libtool.

Cas que j'ai rencontrés Partie 1. Il a été reconnu que cela fonctionnerait si la libtool réelle et ltmain.sh étaient placées, mais lorsqu'il est utilisé dans un environnement libtool de haute version, make échoue. (Créé avec Ubuntu 14.04 → Échec de la compilation avec Ubuntu 18.04) → Dans ce cas, supprimez libtool et ltmain.sh et exécutez autoreconf pour résoudre le problème.

Partie 2. Au contraire, quand j'ai amené le code dans l'ancien environnement libtool, ./configure-> make était terminé, mais Après avoir édité configure.ac → exécution de autoreconf, ni build ni autoreconf ne peuvent être exécutés. (J'ai essayé Ubuntu 18.04 → Cent OS 5.1)

Si vous ne faites rien, ./configure et make peuvent être faits, mais hmm, je n'en suis pas sûr.

Il est facile de suivre le problème car il est fait correctement avec un bon OSS ici, Je suis sceptique sur diverses choses si je le fais moi-même, donc je pense que c'est l'un des points où le seuil est un peu élevé.

C'est pratique à installer et à utiliser, mais il est difficile de s'y accrocher, il semble donc que vos goûts seront différents. Comment est OSS dans le monde? Je t'ai vu vérifier la version

Si vous rencontrez des problèmes, je les énumérerai ici. CONSEILS d'utilisation de configure (Bien que ce soit une poubelle)

Exemple de code

https://github.com/developer-kikikaikai/speedtest

La bibliothèque présentée ci-dessous a été configurée. https://qiita.com/developer-kikikaikai/items/d8839eae7f4491e01671

référence

http://nopipi.hatenablog.com/entry/2013/01/14/025509 https://qiita.com/impepc/items/1bfdfe8ad741def10948 http://capm-network.com/?tag=autotools%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA%E6%A7%8B%E6%88%90%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AB https://stackoverflow.com/questions/28972112/autotools-setup-for-static-and-shared-libraries?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa http://d.hatena.ne.jp/kakurasan/20090512/p1

Recommended Posts

Présentation de la configuration de la bibliothèque personnalisée
Recommandation de la bibliothèque binpacking de python
Bibliothèque pratique TF-Slim de Tensorflow
Liste des images Docker personnalisées
Présentation de la bibliothèque de création TestData Mimesis
Début de l'auto-construction OS 1. Construction de l'environnement