WITH_CXX or not WITH_CXX

[fperignon]

A short issue (since Vincent likes this) : at the time, the option WITH_CXX=OFF does not work.
The idea is to compile externals+numerics only in C, which may be useful for specific env where only C compiler is available.
The question is : Is it really worth it to make it work?

[xhub]

I already did all the work for removing the cpp specific part in the
numerics python module. Now it is always compiled as a C module.

A simple

cmake -DWITH_CXX=0 -DCOMPONENTS="externals;numerics" ~/siconos
make
ctest
make install

works for me. We could improve things a little bit by adding some logic
to disable the components written in C++ if WITH_CXX=OFF. We should also
add a test on CI to check that it works and will continue to do so.

I think a WITH_FORTRAN option would also be nice for Windows ... but
that's a different issue.

Olivier

• Perignon notifications@github.com [2016-03-11 07:25:28 -0800]:

A short issue (since Vincent likes this) : at the time, the option WITH_CXX=OFF does not work.
The idea is to compile externals+numerics only in C, which may be useful for specific env where only C compiler is available.
The question is : Is it really worth it to make it work?

---

Reply to this email directly or view it on GitHub:
#20

[vacary]

@xhub Cool. I will try to import a C version in LMGC90.

@radarsat1 told me that ninja build system does not support FORTRAN. Another interest to try to set up a WITH_FORTRAN option.

[xhub]

• Vincent Acary notifications@github.com [2016-03-11 09:04:27 -0800]:

@radarsat1 told me that ninja build system does not support FORTRAN. Another interest to try to set up a WITH_FORTRAN option.

Yeah but we loose all our event-driven integrators then (LSODAR + HEM5).
If we want more than numerics, this is an issue. We should add an option to use the ones from SUNDIALS.

For the windows build I have to use Unix MakeFiles because it looks
nontrivial to have gfortran called from a VS project file.

[radarsat1]

To be more specific it's really CMake that doesn't support Fortran as a Ninja target. Although I haven't read the whole thread, maybe there are some Fortran specifics that are hard to support in Ninja. But that's more of a CMake bug than a Siconos one ;) However, not likely to be fixed soon, I guess. I found it speeds things up quite a bit during a modify-compile cycle (while working with Gazebo), but it's only a nicety.

[vacary]

Should we add a feature request for the option WITH_FORTRAN ?

We will "only" lost one QP solvers, ODEPACK and HEM5. If we don't care to use an event--driven time--stepping scheme, siconos is usable without FORTRAN. In that case, we have to put some preprocessing instructions in Lsodar.cpp and HEM5.cpp

[radarsat1]

Could be interesting, although I have no idea if that would actually enable the Ninja build... it's possible that any reference to Fortran in CMakeLists.txt would make it impossible. Perhaps I'll test it.

[xhub]

Should we add a feature request for the option WITH_FORTRAN ?

Yes, alongside with one to support sundials solver (there is a package for both ubuntu and fedora). I'm not knowledgeable enough on those integrator to know which one is better.

We will "only" lost one QP solvers, ODEPACK and HEM5. If we don't care to use an event--driven time--stepping scheme, siconos is usable without FORTRAN. In that case, we have to put some preprocessing instructions in Lsodar.cpp and HEM5.cpp

Yes and I'm not comfortable distributing a binary package using HEM5 because of the license for MA28. Also the most recent version of ql0001 is released under a pretty restrictive license. Old version are ok (there is one in scilab) and our should be I think, but I'm not sure. So from a distribution point of view, we only loose ODEPACK.

[xhub]

I've opened #22 for a WITH_FORTRAN option and committed a CI config that test that option. Should be all set