J'utilise Xcode (GCC) pour compiler ma suite de test de boost et il faut trop de temps.
Les tests sont des tests factices minimes, mais il faut plusieurs secondes (environ 20) pour les compiler: < Pré> xxx
Le manuel suggère d'utiliser la version de la bibliothèque pour accélérer la compilation. Cependant, je suis inquiet que cela ne fonctionne pas - Xcode ne reconstruit que mes tests uniquement. L'ensemble de la framework n'est plus compilé car les fichiers d'objet existent.
Je suppose que c'est la quantité de fichiers d'en-tête et de modèles à Boost.Test responsable de la majeure partie du temps de compilation. < P> Avez-vous une idée de la compilation de manière significative plus rapide? L'utiliserait comme œuvre de bibliothèque? Y compris seulement des parties de Boost.test travail?
Toute aide est grandement appréciée!
3 Réponses :
Essayez d'utiliser des en-têtes précompilés, cela devrait réduire le temps de compilation. Les détails peuvent être trouvés ici: http://www.boost.org/boost-build2 /doc/html/bbv2/Reference/procompiled_headers.html
La raison pour laquelle il est lent de compiler est parce que Parce que je suis trop paresseux pour construire la bibliothèque, une alternative que j'ai utilisée est d'avoir un fichier source (qui ne change jamais, de manière rarement reconstruite) incluent le test complet de Boost, puis tout le test réel Les sources incluent juste boost / test / inclus / unité_test.hpp est énorme. L'utilisation d'une bibliothèque le rend plus rapide car l'énorme en-tête est compilé lorsque la bibliothèque est construite et non par la suite. Vos tests incluent ensuite un ensemble plus petit d'en-têtes, conduisant à des heures de construction plus courtes.
boost / test / unité_test.hpp . Cela donne la majeure partie des avantages de l'utilisation de la bibliothèque.
WOW - C'était une réponse utile. Merci beaucoup! Fonctionne comme un charme :-)
Pourriez-vous, s'il vous plaît, expliquez-vous un peu plus? Voulez-vous dire que vous avez un fichier .cpp , où vous n'inclusisez simplement
@Eenoku je ne l'ai pas construit comme une bibliothèque partagée - c'est juste un fichier source ordinaire, si très court, le fichier source qui, lorsqu'il est compilé produit un fichier d'objet que je lie avec tous les autres. (Si vous souhaitez une bibliothèque, vous devez absolument suivre le processus de construction documenté.)
Je pense que toutes les options sont désormais décrites dans la documentation officielle (voir Variantes d'utilisation em> ).
Le Variante d'utilisation de la bibliothèque statique forte> est très pratique et réduit considérablement les temps de compilation . Comme décrit là-bas, on peut créer un fichier source unique, notamment deux lignes, compilez-la séparément et relier celui avec les autres tests. P>
Un commentaire concernant les documents liés. Je crois qu'il existe une erreur dans cette page, à savoir ici: P>
Un et
une seule unité de traduction forte> doit inclure les lignes suivantes: p> #define BOOST_TEST_MODULE test module name #include <boost/test/included/unit_test.hpp>
Avez-vous essayé Clang? Cela pourrait être plus rapide. Vous pouvez définir ceci dans les paramètres de construction. C ++ compile généralement lentement, surtout lors de l'utilisation de lots et de nombreux fichiers d'en-tête.
Bonjour wpt, je n'ai pas mais j'ai fait maintenant. Malheureusement, Clang n'est pas sensiblement plus rapide pour les cas de test. Mais merci, je ne connaissais pas encore Clang!