On Thu, Jan 13, 2011 at 12:13 AM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
The EIGEN2_SUPPORT way seems much more powerful. Let's be specific. If
project A wants to use Eigen3 as well as a lib B which relies on
Eigen2 then there are two cases:
1 - lib B is a pure template lib (or at least the parts which rely on
Eigen2) then EIGEN2_SUPPORT should do the job (we can make it better
if needed).
2 - lib B is a binary library with a public API involving Eigen2
objects. Then there is still the possibility to recompile B with
Eigen3+EIGEN2_SUPPORT.
3 - lib B is a binary library without Eigen2 in the public API. Again, there exists the possibility to recombile B with Eigen3+EIGEN2_SUPPORT.
Asumming for a moment we had Eigen:: and Eigen3:: namespaces. This would imply the following things.
For case 1)
None of the Eigen:: (v2) based libraries were anymore compatible with Eigen3. The public functions in library B would not be accepting any Eigen3 objects, nor could objects from the two versions be automatically converted to each other.
Solution: adapt B (rename, etc.)
For case 2)
The public interface from lib B which we assume for now to be still using Eigen:: (v2) objects suddenly becomes useless since there is no conversion from Eigen3:: to Eigen:: objects.
Solution: adapt B + recombile
For case 3)
This case will be solved with different namespaces.
That means, the different namespaces bring advantages in case 3) only.
Some drawbacks of this approach:
I) Eco-system which already made the move to Eigen3 (maybe with EIGEN2_SUPPORT) need
a) renaming the namespace and all libraries (which is easy) and
b) recompilation of all binary libraries and their dependencies
Our group is living in such an eco-system (without the need for EIGEN2_SUPPORT) with ~60 users and many many libraries. Even though the renaming could be done by a single person via grep every single user would have to pull in the changes and recompile every binary library and app.
II) Template libraries from case 1) are not compatible with any Eigen3 libraries and we can expect plenty of them being already around in the wilderness. This is also the case for libraries from case 2) but they would not even link in mixed environments. In case 1), I think it is hardly possible to let Eigen2 and Eigen3 co-exist when we were using different namespaces.
III) Major future versions of Eigen would be incompatible with all previous version...
Finally, I would like to ask whether OpenCV is really using Eigen2? From what I have seen so far, they have a single template header file (eigen.hpp) which offers conversion functions from Eigen::Matrix to CvMat and vice versa. Regarding kdl (
http://www.orocos.org/kdl), I tried to compile it against Eigen3+EIGEN2_SUPPORT and the major hickup I am seeing is caused by Map's const-correctness. We should be able to fix that through the plugin by re-enabling the non-const constructor of Maps though I did not properly think this over.
Regards,
Hauke