I am suspecting now that _libVersions.cpp can detect some atypical configurations in the system. So far we had problems with:
1. #include <metis.h> in https://answers.launchpad.net/yade/+question/680867 2. #include <mpi.h> in https://answers.launchpad.net/yade/+question/681091 Somehow they passed the cmake detection step, and in _libVersions.cpp there is an #ifdef guard: 1. for #include <metis.h> #if defined(LINSOLV) || defined(YADE_POTENTIAL_PARTICLES) || defined(YADE_POTENTIAL_BLOCKS) || defined(FLOW_ENGINE) 2. for #include <mpi.h> in #ifdef YADE_MPI So cmake defines the YADE_MPI and those that use <metis.h>, but then those files were not found. With metis it turned out that there were two packages with similar name in gentoo. I am curious what will be the explanation here in MPI case on Xenial. I suppose that we would have to fix this inside cmake. I am not sure how, though. OTOH I can make _libVersions.cpp to be totally bulletproof by putting this line: 1. for #include <metis.h> #if defined(METIS_VER_MAJOR) && defined(METIS_VER_MINOR) && defined(METIS_VER_SUBMINOR) 2. for #include <mpi.h> in #if defined(OMPI_MAJOR_VERSION) && defined(OMPI_MINOR_VERSION) && defined(OMPI_RELEASE_VERSION) 3. similarly for everything else. but I am afraid that it is only deferring problems to the later stage - yade will compile, but something won't work. what do you think? Janek Bruno Chareyre said: (by the date of Mon, 27 May 2019 23:59:15 +0200) > Hi Janek, > Not sure I understand correctly this problem but, it seems we are not > switching off features automatically when a package is optional? That was > usual behavior and it would probably raise less questions. > Do I miss something? > Bruno -- Janek Kozicki http://janek.kozicki.pl/ | _______________________________________________ Mailing list: https://launchpad.net/~yade-dev Post to : yade-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~yade-dev More help : https://help.launchpad.net/ListHelp