geographiclib: files missing from install

[crmoore (Chris Moore)]

The following files are not installed by the port, but are by the upstream cmake build system.

$prefix/lib/cmake/GeographicLib/geographiclib-config-version.cmake
$prefix/lib/cmake/GeographicLib/geographiclib-config.cmake
$prefix/lib/cmake/GeographicLib/geographiclib-targets-release.cmake
$prefix/lib/cmake/GeographicLib/geographiclib-targets.cmake

The upstream provides several build systems (autotools and cmake among others), and documents cmake as preferred.

Not sure what the macports policy is on how to choose which one to use, but the installed fileset is slightly different with each.

[mf2k (Frank Schima)]

In the future, please use WikiFormatting.

Please do not Cc openmaintainer@… because it is not a valid email address.

[ryandesign (Ryan Carsten Schmidt)]

Replying to crmoore@…:

The following files are not installed by the port, but are by the upstream cmake build system.

Upstream provides both a cmake build system and an autotools build system. This port happens to use the autotools build system. I see that the installation instructions do state that the cmake build system is preferred. Maybe the port should switch to using that. In that case, the use of the cmake 1.0 portgroup is advised. If this changes the files that are installed by the port, the port's revision would need to be increased.

[lockhart (Thomas Lockhart)]

Not familiar with cmake. Does the original poster want to contribute patches to convert from autotools to cmake? afaict this only benefits folks who are using cmake for other builds; not sure why that is a problem for a port to solve.

[crmoore (Chris Moore)]

Portfile diff to use cmake build system

[crmoore (Chris Moore)]

Portfile patch to use cmake.

You are right, that this only benefits those of us using cmake to depend on this port. I don't know if it is macport's problem to solve.

If the intention of this port is only to satisfy dependencies of other ports, the existing port is fine. If it is to allow external software to compile and link against it, following upstream imposes less friction to those following upstream's documentation.

Note other differences in the installed file list:

- lib/libGeographic.la
- share/cmake/GeographicLib/FindGeographicLib.cmake

+ lib/cmake/GeographicLib/geographiclib-config-version.cmake
+ lib/cmake/GeographicLib/geographiclib-config.cmake
+ lib/cmake/GeographicLib/geographiclib-targets-release.cmake
+ lib/cmake/GeographicLib/geographiclib-targets.cmake
+ lib/libGeographic.14.2.1.dylib

+ more docs installed with cmake

[lockhart (Thomas Lockhart)]

Would crmoore like to become a maintainer or co-maintainer for this package? I'd be happy to have that happen so we have some cmake expertise for this port.

[crmoore (Chris Moore)]

I can help out as a co-maintainer if desired. What's involved?

[lockhart (Thomas Lockhart)]

Replying to crmoore@…:

I can help out as a co-maintainer if desired. What's involved?

Well, you are doing it already. Noticing when a new version is available, updating the port to fix packaging issues or to fix breakage in the upstream distro, responding (helpfully or not) to new tickets. For this case, you would have submitted your patches and included "haspatch maintainer" in the keywords field. The powers-that-be see that and figure that you've done your homework on the patch and hours or days later the patch is magically applied to the MacPorts repo and the ticket gets signed off as "closed". If you are not a maintainer, you might have the experience you just had: the maintainer kind-of doesn't know much about what you are wanting to do, so the whole process kind-of stalls. As co-maintainers we have each other as a resource to work out issues and can each respond to new tickets etc. In my experience the most annoying part of being a maintainer is trying to support OS releases that you don't have and to respond to issues which Work For Me. But that is just the way it goes I think. The more maintainers the better in that regard. I've also found that if you do something "wrong" (not using the recommended style for ticket titles, not knowing The Best Way to write the port) the MacPorts uber-maintainers will give advice or jump in to fix things up. I've done several ports from scratch and taken over a few and it has been a positive experience. Now if I can just figure out how to clear some of those old Works For Me tickets...

[crmoore (Chris Moore)]

Sounds good. Should I file another ticket to add myself as a maintainer, or add a patch here?

[lockhart (Thomas Lockhart)]

Great to have you! Let's see if we hear from someone (Ryan has already communicated here and has been helpful in the past). Give it a few days and then we'll try filing a separate ticket.

[kurthindenburg (Kurt Hindenburg)]

Cc Me!

[kurthindenburg (Kurt Hindenburg)]

I went ahead and update to 1.46; included your cmake changes and added crmoore as co-maintainer

Let me know if I broke anything

r148678