Closed dcoeurjo closed 8 years ago
I agree boost::spirit is a problem. Perhaps the flag could be called WITH_POLYNOMIAL_PARSER, but, for users, to put the flag ON by default. What do you think ?
Le 13/03/2015 09:50, David Coeurjolly a écrit :
There are too much issues between boost::spirit, GCC and Polynomial stuff in DGtal. Travis has a non-deterministic behavior when building the lib on GCC.
I suggest to move the reader to as an optional tool activated using a WITH_POLYNOMIAL flag at cmake stage.
This is straightforward but may impact several classes and tools
cc @kerautret https://github.com/kerautret @JacquesOlivierLachaud https://github.com/JacquesOlivierLachaud
— Reply to this email directly or view it on GitHub https://github.com/DGtal-team/DGtal/issues/975.
and thus disable the parser in travis ?
Ok for this but if travis complains, it means that for gcc users, the dgtal examples/tools may not compile.
Maybe we could sort a little bit the WITH_* entries. Some of them are marginal (Patate, ...) others are highly recommended (qglviewer, GMP, poly. parser...).
Yes for the tools we can add a tab in the main DGtalTools info to give the dependance of the tools which will not always be compilled ?or perhaps a message in Cmake indicating that some tools will be missing..
Okay with @JacquesOlivierLachaud 's solution: the bug may be only due to travis VM RAM limit. Ok with the option set to true by default (expect for travis)
MPolynomial seems to be fine on Travis boost version.. Maybe we don't need such thing. Closing
There are too much issues between boost::spirit, GCC and Polynomial stuff in DGtal. Travis has a non-deterministic behavior when building the lib on GCC.
I suggest to move the reader to as an optional tool activated using a WITH_POLYNOMIAL flag at cmake stage.
This is straightforward but may impact several classes and tools
cc @kerautret @JacquesOlivierLachaud