2009-05-30 7 views
0

Ma question principale est que les autotools ont créé des liens vers INSTALL, COPYING, missing, install-sh et depcomp. Quand j'ai essayé de les voir, j'ai vu qu'ils étaient téléchargés en tant que liens, donc je les ai remplacés par de vrais fichiers afin qu'ils soient visibles. Est-ce que je manque quelque chose de fondamental? Quand je déballe mon fichier gz de make dist 'c'est à quoi il ressemble:Les liens générés par autotools doivent être remplacés avant le téléchargement?

Arbre de distribution (Minus répertoires Source)

 
-rw-r--r-- 1 ojblass users 18591 2009-05-30 03:23 Makefile.in 
-rwxr-xr-x 1 ojblass users 136168 2009-05-30 03:20 configure 
drwxr-xr-x 3 ojblass users 4096 2009-05-30 03:20 autom4te.cache 
-rw-r--r-- 1 ojblass users 32230 2009-05-30 03:20 aclocal.m4 
-rw-r--r-- 1 ojblass users 251 2009-05-30 03:20 configure.ac 
-rw-r--r-- 1 ojblass users 626 2009-05-30 03:11 AUTHORS 
-rwxr-xr-x 1 ojblass users 120 2009-05-30 03:11 autogen.sh 
-rw-r--r-- 1 ojblass users 737 2009-05-30 03:11 ChangeLog 
-rw-r--r-- 1 ojblass users 35147 2009-05-30 03:11 COPYING 
-rwxr-xr-x 1 ojblass users 17867 2009-05-30 03:11 depcomp 
-rwxr-xr-x 1 ojblass users 199 2009-05-30 03:11 example.pl 
-rwxr-xr-x 1 ojblass users 152 2009-05-30 03:11 example.sh 
-rw-r--r-- 1 ojblass users 9512 2009-05-30 03:11 INSTALL 
-rwxr-xr-x 1 ojblass users 13620 2009-05-30 03:11 install-sh 
-rw-r--r-- 1 ojblass users 215 2009-05-30 03:11 Makefile.am 
-rwxr-xr-x 1 ojblass users 11135 2009-05-30 03:11 missing 
-rw-r--r-- 1 ojblass users  75 2009-05-30 03:11 NEWS 
-rwxr-xr-x 1 ojblass users 507 2009-05-30 03:11 profile.sh 
-rw-r--r-- 1 ojblass users 2605 2009-05-30 03:11 README 
-rw-r--r-- 1 ojblass users 201 2009-05-30 03:11 README_developers 
-rwxr-xr-x 1 ojblass users 382 2009-05-30 03:11 run.sh 
-rw-r--r-- 1 ojblass users 481 2009-05-30 03:11 TODO 
-rwxr-xr-x 1 ojblass users 117 2009-05-30 03:11 usefull.sh 

Je prévois sur l'élimination des README_developers et de faire deux sections le fichier README. Je cherche aussi à supprimer run.sh et profile.sh et à les intégrer à une cible de test make (quelques lectures sont nécessaires). Je ne pense pas qu'un objet TODO appartienne à la distribution source, mais peut-être que c'est acceptable de l'avoir dans l'arborescence source du projet. Tout pointeur supplémentaire au-dessus et au-delà de la question des liens est apprécié.

Répondre

1

Réponse courte: Laissant ces liens symboliques (autres que l'installation) serait truqué la conformité à GNU coding standards.

par automake par défaut pour effectuer un contrôle de la conformité aux normes GNU (nécessite des fichiers suivants existent: INSTALL, NOUVELLES, README, , COPIES AUTEURS et ChangeLog). On peut tourner de cette vérification (et supprimer en toute sécurité certains de ces fichiers) en passant l'option --foreign automake (pour le faire éditer autogen.sh et le relancer).

Les liens ont été créés lorsque automake a été invoqué avec --add-missing options qui sauf si l'option --copy a été créée crée des liens symboliques pour fichiers manquants plutôt que de les copier. C'est afin de garder ces fichiers à jour (en fait, INSTALLER seulement) à jour chaque fois que vous installez le nouveau automake. Regerding réponse de Jonathan ces liens symboliques ne sont pas un problème: tous les fichiers distribués sont copiés pour séparer le répertoire avant de faire tarball. Modifiez-les en fichiers standard si vous souhaitez les modifier.

D'autres fichiers (README_developers, run.sh, profile.sh, TODO etc.) ont probablement été générés par l'IDE que vous utilisez et ajouté à EXTRA_DIST variable supérieure Makefile.am. Vous pouvez les supprimer de la distribution en éditant EXTRA_DIST et par la suite, vous pouvez également supprimer de la source.

Le reste est généré automatiquement par autoconf et automake:

  • aclocal.m4
  • autom4te.cache
  • configure
  • depcomp
  • install-sh
  • Makefile.in
  • manquant

Si vous souhaitez désencombrer davantage votre répertoire source principal, vous pouvez ajouter AC_CONFIG_AUX_DIR([scripts]) à configure.ac. De cette façon certains des scripts trouveront place dans le répertoire scripts.

Mise à jour:

Les normes de codage GNU décrivent simplement l'exigence de ces fichiers de documentation pour être présent dans la distribution et ce information devrait y être inclus. L'option --add-missing est de rappeler au programmeur quels fichiers doivent être écrits. De toute évidence, avoir un fichier vide NEWS ou AUTHORS ne rendra pas le projet plus conforme à la norme.

Seul le fichier ChangeLog a un requirements rigide sur son format. Dans certains projets, ChangeLog est automatiquement généré à partir des messages de validation formalisés . Sur Darcs, c'est simplement darcs changes >ChangeLog. Si vous utilisez Subversion, vous pouvez consulter: svn2log, svn2cl. Comme mentionné ci-dessus, le fichier INSTALL peut être raisonnable à conserver en tant que lien symbolique mais uniquement si aucune information spécifique au projet n'est requise concernant l'installation (c'est-à-dire aucun argument de script de configuration supplémentaire, etc.).

+0

Que se passe-t-il si quelqu'un d'autre empaquette le produit ou télécharge la source à partir de SourceForge qui a des fichiers différents dans ces emplacements? Pouvez-vous élaborer davantage sur cette norme GNU que vous avez référencée? Est-ce qu'il mentionne spécifiquement la gestion de ces fichiers pour la conformité? – ojblass

+0

Lorsque quelqu'un télécharge l'archive tar de distribution qu'il a des copies (pas de liens symboliques ) des fichiers que vous avez. La différence peut survenir lorsque la source est tirée du système de gestion de contrôle de source (système de contrôle de version) et que ces fichiers/liens symboliques ne sont pas inclus dans le référentiel. Par conséquent, je préfère les traiter comme des fichiers et les mettre sous contrôle de version. – lispmachine

+0

Merci de votre offre! – ojblass

1

Le fichier TODO peut aller dans la distribution; C'est une indication pour les consommateurs de choses que vous pensez être déficientes dans le produit, et ils sont un indice pour les contributeurs potentiels dans les domaines où ils pourraient peut-être aider à améliorer le produit. (De même, si vous tombiez sous un bus, cela aiderait d'autres personnes à prendre le relais en utilisant le matériel de version actuel.)

Il peut être utile d'utiliser un sous-répertoire pour contenir la majeure partie du matériel de configuration.

En ce qui concerne votre question principale - est-ce que les fichiers 'liens' ou 'liens symboliques'? Les liens symboliques sont moins utiles pour l'empaquetage sauf si vous dites à (GNU) tar de les suivre quand même ('-h' ou '--dereference'). Si les seuls liens symboliques sont à ces fichiers, cela fonctionne; Si vous utilisez des liens symboliques dans la distribution elle-même, cela peut être plus contre-productif.

+0

En regardant la sortie ls avec le nombre de liens == 1, il est facile de dire que ce sont des liens symboliques et non des liens physiques. – lispmachine

+0

erm .. maintenant je lis que ce sont des fichiers réguliers de tarball de distribution déballé – lispmachine

+0

Pour être parfaitement clair, ceux-ci ne sont pas de la balle tar, mais un téléchargement des fichiers de sourceforge. ils descendent comme des liens vers des fichiers inexistants sur certaines machines lorsque vous récupérez la source. Si ceux-ci n'existent pas, la boule tar ne les aura pas. Ces choses sont un peu moins qu'évidentes. Mais en regardant SourceForge incriminer, j'ai trouvé quelque chose qui semble raisonnable dans la mesure où les structures vont. Je vais laisser cette question de côté un peu plus longtemps. – ojblass

Questions connexes