Je commence à m'intéresser à Boost. Mieux vaut tard que jamais :-)
Du coup je découvre aussi Boost.build.
Alors, en espérant ne pas être trop hors sujet et en espérant ne pas
lancer un troll non plus, je voudrais savoir si tous les expérimentés de
la construction de projets C++ que vous êtes, pensez que Boost.build est
une bonne alternative à make ou bien est-ce que vous préférez restez
avec ce bon vieux make ?
Je commence à m'intéresser à Boost. Mieux vaut tard que jamais :-) Du coup je découvre aussi Boost.build. Alors, en espérant ne pas être trop hors sujet et en espérant ne pas lancer un troll non plus, je voudrais savoir si tous les expérimentés de la construction de projets C++ que vous êtes, pensez que Boost.build est une bonne alternative à make ou bien est-ce que vous préférez restez avec ce bon vieux make ?
Je suis pas fan perso, c'est assez lourd comme truc. En ce moment j'expérimente scons.
L'avenir est à cmake.
Bonjour à tous,
Je commence à m'intéresser à Boost. Mieux vaut tard que jamais :-)
Du coup je découvre aussi Boost.build.
Alors, en espérant ne pas être trop hors sujet et en espérant ne pas
lancer un troll non plus, je voudrais savoir si tous les expérimentés
de la construction de projets C++ que vous êtes, pensez que
Boost.build est une bonne alternative à make ou bien est-ce que vous
préférez restez avec ce bon vieux make ?
Je suis pas fan perso, c'est assez lourd comme truc.
En ce moment j'expérimente scons.
Je commence à m'intéresser à Boost. Mieux vaut tard que jamais :-) Du coup je découvre aussi Boost.build. Alors, en espérant ne pas être trop hors sujet et en espérant ne pas lancer un troll non plus, je voudrais savoir si tous les expérimentés de la construction de projets C++ que vous êtes, pensez que Boost.build est une bonne alternative à make ou bien est-ce que vous préférez restez avec ce bon vieux make ?
Je suis pas fan perso, c'est assez lourd comme truc. En ce moment j'expérimente scons.
L'avenir est à cmake.
fabien.chene
"kanze" writes:
Fabien Chêne wrote:
[en ce qui concerne jam...]
Ses principaux points forts, AMHA :
-- jam gère tout seul Les dépendances des includes; pas besoin de demander de l'aide au compilateur via -MM -MD -MT ou du genre... (il se débrouille aussi avec les dépendances de templates exporté, mais je crois qu'icc fait tout le boulot)
Je viens d'y jeter un coup d'oeil rapide aux docs. Et je suis tombé sur un os. Justement, parce qu'il évalue les dépendances lui-même, il utilise des règles différentes que le compilateur, et en particulier : « Also, scanning for regular expressions only works where the included file name is literally in the source file. It can't handle languages that allow including files using variable names (as the Jam language itself does). » Et aussi, comme le C et le C++. Ça veut dire que dans la pratique, je ne pourrais pas m'en servir, parce que j'ai bien des choses du genre : #include GB_dependentInclude(conf,gb/config.hh) #include GB_dependentInclude(comp,gb/compiler.hh) #include GB_dependentInclude(sysFamily,gb/system.hh) dans tous mes fichiers. C'est bien beau, mais si ça ne marche pas pour le C et le C++, ça ne m'est pas bien utile.
Peut-être une des extensions de Boost règlent ce problème ?
(des mois après) J'étais allé demander sur la mailing list de Boost.Build, et Dave Abrahams m'avait répondu que la bibliothèque Boost - je pense qu'il évoquait en particulier Boost.MPL et ses techniques de « preprocessor meta-programming » - utilisait ce type d'include et qu'ils ne voulait justement pas créer un dépendance. En plus du fait que c'était très difficile à résoudre.
-- Fab
"kanze" <kanze@gabi-soft.fr> writes:
Fabien Chêne wrote:
[en ce qui concerne jam...]
Ses principaux points forts, AMHA :
-- jam gère tout seul Les dépendances des includes; pas besoin de
demander de l'aide au compilateur via -MM -MD -MT ou du
genre... (il se débrouille aussi avec les dépendances de templates
exporté, mais je crois qu'icc fait tout le boulot)
Je viens d'y jeter un coup d'oeil rapide aux docs. Et je suis
tombé sur un os. Justement, parce qu'il évalue les dépendances
lui-même, il utilise des règles différentes que le compilateur,
et en particulier : « Also, scanning for regular expressions
only works where the included file name is literally in the
source file. It can't handle languages that allow including
files using variable names (as the Jam language itself does). »
Et aussi, comme le C et le C++. Ça veut dire que dans la
pratique, je ne pourrais pas m'en servir, parce que j'ai bien
des choses du genre :
#include GB_dependentInclude(conf,gb/config.hh)
#include GB_dependentInclude(comp,gb/compiler.hh)
#include GB_dependentInclude(sysFamily,gb/system.hh)
dans tous mes fichiers. C'est bien beau, mais si ça ne marche
pas pour le C et le C++, ça ne m'est pas bien utile.
Peut-être une des extensions de Boost règlent ce problème ?
(des mois après) J'étais allé demander sur la mailing list de
Boost.Build, et Dave Abrahams m'avait répondu que la bibliothèque
Boost - je pense qu'il évoquait en particulier Boost.MPL et ses
techniques de « preprocessor meta-programming » - utilisait ce type
d'include et qu'ils ne voulait justement pas créer un dépendance.
En plus du fait que c'était très difficile à résoudre.
-- jam gère tout seul Les dépendances des includes; pas besoin de demander de l'aide au compilateur via -MM -MD -MT ou du genre... (il se débrouille aussi avec les dépendances de templates exporté, mais je crois qu'icc fait tout le boulot)
Je viens d'y jeter un coup d'oeil rapide aux docs. Et je suis tombé sur un os. Justement, parce qu'il évalue les dépendances lui-même, il utilise des règles différentes que le compilateur, et en particulier : « Also, scanning for regular expressions only works where the included file name is literally in the source file. It can't handle languages that allow including files using variable names (as the Jam language itself does). » Et aussi, comme le C et le C++. Ça veut dire que dans la pratique, je ne pourrais pas m'en servir, parce que j'ai bien des choses du genre : #include GB_dependentInclude(conf,gb/config.hh) #include GB_dependentInclude(comp,gb/compiler.hh) #include GB_dependentInclude(sysFamily,gb/system.hh) dans tous mes fichiers. C'est bien beau, mais si ça ne marche pas pour le C et le C++, ça ne m'est pas bien utile.
Peut-être une des extensions de Boost règlent ce problème ?
(des mois après) J'étais allé demander sur la mailing list de Boost.Build, et Dave Abrahams m'avait répondu que la bibliothèque Boost - je pense qu'il évoquait en particulier Boost.MPL et ses techniques de « preprocessor meta-programming » - utilisait ce type d'include et qu'ils ne voulait justement pas créer un dépendance. En plus du fait que c'était très difficile à résoudre.
