Est-il possible de spécifier un chemin d'inclusion C / C ++ vers un serveur de préprocesseur distant?
Le point ici est d'avoir un emplacement central pour les fichiers d'en-tête. Cela rend les mises à jour, la cohérence des versions et une foule d'autres choses bien meilleures que les personnes exécutant tout bon gré mal gré, y compris différentes versions de choses.
Exemple minimal, complet et vérifiable
Inclut typique. Sous Linux, serait par défaut / usr / include / ou similaire; dans Windows VS, à un emplacement spécifié dans la variable $ (IncludePath) .
#include <192.0.2.17://iostream>
int main() {
std::cout << "hello, world" << std::endl;
}
Imaginons maintenant que nous définissions notre chemin d'inclusion comme suit:
C_INCLUDE_PATH=192.0.2.17://usr/include;/usr/include;
Ce qui précède vérifierait d'abord le serveur distant à 192.0.2.17 pour voir si la bibliothèque iostream existait. À défaut, / usr / include serait coché.
Ceci est un peu exagéré pour illustrer le point:
#include <iostream>
int main() {
std::cout << "hello, world" << std::endl;
return 0;
}
Merci, Keith: ^)
3 Réponses :
Je ne connais aucun compilateur qui récupère des fichiers ou des bibliothèques d'inclusion à distance, donc ce n'est pas quelque chose que vous pouvez faire directement.
Le mieux que vous puissiez faire est d'avoir ces dépendances sur un partage NFS que vous pouvez monter, puis d'ajouter ce chemin à votre chemin d'inclusion.
Je ne ferais pas référence à cela dans le code comme ça, et comme l'a dit dbush, il faudrait améliorer le préprocesseur.
Mais il peut y avoir de jolies façons de faire cela dans le système Make. Autrement dit, si vous utilisez Make (par exemple), vous pouvez ajouter des étapes au Makefile qui forcent une actualisation des données.
Cependant, je dirais que c'est FAUX car ce ne sont pas seulement les fichiers d'inclusion qui doivent être frais. Si une inclusion a changé, le code associé a probablement également changé et vous auriez également besoin de ces modifications. Vos trucs magiques #include ne feront rien pour vous assurer que les gens ont le bon code / les bonnes bibliothèques pour les inclusions.
Je ne sais pas pourquoi une bonne utilisation des référentiels de code source ne gère pas déjà cela pour vous.
Puisque vous voulez quand même contrôler la version , vous pouvez simplement utiliser git (comme des milliers d’autres projets). Ainsi, chaque utilisateur dispose d'un clone local de tout ce dont il a besoin.
Pour répondre à la question initiale: Non. Je ne connais aucun préprocesseur prenant en charge un tel schéma d'inclusion.
Je pense que vous devez monter un lecteur distant à la place. sshfs pourrait fonctionner sur la plupart des machines Linux et une sorte de partage NFS ou SAMBA pourrait fonctionner pour Windows. Ensuite, vous définiriez votre directive INCLUDE_PATH pour qu'elle pointe vers le lecteur partagé.
Downvote veuillez revoir les critères et expliquer. C'est une question bien réfléchie. stackoverflow.com/help/privileges/vote-down
Pourquoi ne pas simplement utiliser git ?
@JesperJuhl git obligerait chaque utilisateur à cloner un dépôt et à avoir une copie locale séparée, n'est-ce pas?
@kmiklas Oui. Mais vous voulez un contrôle de version de toute façon , alors pourquoi est-ce un problème?
@JesperJuhl hmmmm ....... pouvez-vous ajouter cela comme une vraie réponse?
@kmiklas Terminé ..
Pour ce que ça vaut, ce que vous proposez me semble sortir du champ d'application du langage C ++. C'est vraiment une extension de la façon dont le système hôte interprète les systèmes de fichiers et les noms de fichiers.