Pull GeographicLib into develop.

Issue #32 resolved
Frank Dellaert created an issue

I'm not an expert on the cmake structure, so someone needs to dot the i's on this new third-party library and make sure it works with all cmake flags. After fixing that in 2.4, it needs to be pulled into 3.0.

Comments (23)

  1. Richard Roberts

    @fdellaert For this, does it suffice to just merge 2.4 into develop? That brings some new factors as well.

  2. Frank Dellaert reporter

    No, I think you would need to dot the i's on this new third-party library and make sure it works with all cmake flags, then merge into develop.

  3. Richard Roberts

    Ok, I took a look. I think the biggest risk is that GeographicLib doesn't compile on somebody's system (at least not with our default compile settings for it) and there needs to be a way to disable it... or alternatively should it be disabled by default? I can put in the flags to disable it if you think that's the best option.

  4. Richard Roberts

    For example on some embedded platform, or due to compiler changes, e.g. on a new Mac os version. Always building it when it will rarely be used seems a little risky, since we'll then be responsible for any compile problems that people have with it.

    On the other hand, I can see how it's useful to include it in GTSAM to convert coordinates. And introducing an option to enable it adds complexity.

    I don't know what's best for this... up to you and I can do it either way.

  5. Frank Dellaert reporter

    No, why do you think this is less likely to compile than everything else? Is there something specific that makes it different?

  6. Frank Dellaert reporter

    If so - and you can identify this - we could add an option to not build it, but I'd like to build it by default.

  7. Richard Roberts

    Not that I know of - it's just a lot of code that we'd be taking on responsibility for. I'll keep it as is for now then, it's anyway not hard to add an option in the future if we decide we need one.

    Everything looked fine to me in the way you set up the library, given the current cmake structure in GTSAM. The linking is a little strange due to the way unit tests are added in GTSAM. I'm working on a feature branch today (adding-scripts-simplify) that fixes a lot of the mess in adding unit tests and examples, so that will help to clean up the way the unit tests link to GeographicLib.

    For now it looks good to merge into develop. I'll simplify it a bit using the changes in the adding-scripts-simplify branch later today. But for now should I merge 2.4 into develop?

  8. Frank Dellaert reporter

    Hold on one second. I will remove RENORM in Sphere2, as suggested by @atrevor , and then we can also release 2.4 as source.

  9. Richard Roberts

    @fdellaert FYI, I also had to disable the unit tests and "tools" in GeographicLib for make check to work correctly. Otherwise it tried to run the GeographicLib unit tests which all fail with a strange error.

    We may also want to consider preventing GeographicLib installing itself... it could overwrite or take precedence over a GeographicLib version that a user already has installed?

  10. Chris Beall

    This actually came up in a meeting Friday, and it was suggested that it could be handled like Eigen? Give the user a choice?

  11. Richard Roberts

    Is it true that the only GeographicLib functions a user would need to interact with GTSAM are those to convert coordinates? If so, what about creating a few "wrapper" functions to do the conversions, and build them into GTSAM, so that we make those functions available without installing GeographicLib?

  12. Richard Roberts

    And then if someone wants to do other things that GeographicLib does, which are not normally necessary for interacting with GTSAM, they can install GeographicLib.

  13. Log in to comment