GeographicLib is available in microsoft's vcpkg utility. I'm not sure where this 'portfile' is maintained (probably by some volunteer), however, it is a little out of date (1.47-patch1-16) instead of the latest release (1.51).
geographiclib:x64-windows 1.47-patch1-16 a small set of C++ classes for performing conver...
When these repositories are hosted on GitHub, adding the vcpkg option --head downloads, builds and installs the code from the repo's head (this is not an option for geographiclib, as the files are hosted in https://git.code.sf.net/p/geographiclib). I'm not sure if there are plans to update the portfile to the latest version.
The vcpkg packaging utility is extremely convenient (almost linux like), especially when coupled with windows hosted CMake projects. All that is needed to integrate them with other cmake projects is to add.
I see that there's a pull request in to support GeographicLib 1.50.1. I'll see about getting the errors in this pull request resolved. Don't hold your breath... but I'll try to get to this within the next 2 weeks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see that there's a pull request in to support GeographicLib 1.50.1. I'll
see about getting the errors in this pull request resolved. Don't hold your
breath... but I'll try to get to this within the next 2 weeks.
there was a problem building with the latest pull request. I have not used pull requests before so I kind of ploughed my way through it.
To reproduce the error, I started with a clean repository with only your pull request (12397) merged locally with the master vcpkg. I then ran the .\bootstrap-vcpkg.bat command to build vcpkg with your changes.
Typically afterwards, I perform a library search for geographiclib, however due to the presence of a trailing comma in the vcpkg.json file, vcpkg got confused and terminated the search early.
After fixing that the trailing comma, search, install and remove succeeded (however you might want to review the usage string) which contains an unexpanded variable ${GographicLib_LIBRARIES} rather than the usual geographic:: aliases - see below. There are additional details over in the pull request, Thanks for doing this so quickly. Nice job. Attached - fixed json file.
John
The package geographiclib:x64-windows provides CMake targets:
Charles, looks like the usage string still needs to be addressed, I just tested the latest updates to your pull request which works fine as far as installation goes (search now returns 3 items per your updated vcpkg json file).
geographiclib 1.50.1 a small set of C++ classes for performing conversions between geographic, UTM,...
geographiclib[default-features] Features installed by default
geographiclib[tools] Build the geographiclib tools
However the resulting usage string is still incorrect - maybe like before you need to consider whether it is static or otherwise to give back the correct alias
The package geographiclib:x64-windows provides CMake targets:
The whole point of using the unexpanded variable, is that this form would continue to work as things changed under the hood. (The older documentation is already out of date.) Given that vcpkg seems to deal with either shared or static libraries (but not both), there's no need to get any more complicated than this. (But the web site does tell you how to select shared/static libraries in more complex setups.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Charles, I am using the ${GeographicLib_LIBRARIES} and although it finds the library, I encountered the following errors associated with one of the tools.
How annoying! The problem is that the tools are all registered as targets and the find_package scripts checks that it can the targets are where they are expected to be. But they aren't because they got moved to tools/geographiclib (from tools). I fix. And thanks for catching this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I re-checked the Linux vcpkg for GeographicLib and it appears something regressed since the successful linux find_package from my last email 7 days ago.
I don’t usually build on Linux, so when I saw the final merge in vcpkg I thought I would give it a quick try agin. The offending line from my CMakeLists.txt is shown below:
find_package(GeographicLib CONFIG REQUIRED)
And here is the corresponding console output:
I suspect a case sensitivity issue, (_find_package) has "GeographicLib" as an argument.
It looks to me like geographiclib isn't installed on you system. find_package(GeographicLib) should find the config files it need in installed/x64-linux/share/geographiclib. What does ./vcpkg list report?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You are correct, the package got removed somehow. I suspect it was uninstalled when I ran a command to cleanup my unused packages with a --recurse flag (I was doing a boost cleanup).
BTW I noticed both these entries this in my CMake variable cache, not sure if the geographiclib_DIR is a leftover vestige.
geographiclib_DIR might be given because you previously did find_package (geographiclib) or some such. Try removing the entire contents of your build directory and trying again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GeographicLib is available in microsoft's vcpkg utility. I'm not sure where this 'portfile' is maintained (probably by some volunteer), however, it is a little out of date (1.47-patch1-16) instead of the latest release (1.51).
geographiclib:x64-windows 1.47-patch1-16 a small set of C++ classes for performing conver...When these repositories are hosted on GitHub, adding the vcpkg option
--headdownloads, builds and installs the code from the repo's head (this is not an option for geographiclib, as the files are hosted in https://git.code.sf.net/p/geographiclib). I'm not sure if there are plans to update the portfile to the latest version.The vcpkg packaging utility is extremely convenient (almost linux like), especially when coupled with windows hosted CMake projects. All that is needed to integrate them with other cmake projects is to add.
"-DCMAKE_TOOLCHAIN_FILE=..../vcpkg/scripts/buildsystems/vcpkg.cmake"to the CMake command line when configuring a project.
John
Last edit: John Coffey 2020-07-09
I see that there's a pull request in to support GeographicLib 1.50.1. I'll see about getting the errors in this pull request resolved. Don't hold your breath... but I'll try to get to this within the next 2 weeks.
Thanks, that would be great.
John
On Fri, Jul 10, 2020 at 7:13 AM Charles Karney karney@users.sourceforge.net
wrote:
I've submitted a pull request for geographiclib-1.50.1 on vcpkg. See
https://github.com/microsoft/vcpkg/pull/12379
If you can you should check this out and report your success/failure as a comment to the PR. This might hurry along the merge of the PR.
Thanks,
there was a problem building with the latest pull request. I have not used pull requests before so I kind of ploughed my way through it.
To reproduce the error, I started with a clean repository with only your pull request (12397) merged locally with the master vcpkg. I then ran the .
\bootstrap-vcpkg.batcommand to build vcpkg with your changes.Typically afterwards, I perform a library search for geographiclib, however due to the presence of a trailing comma in the
vcpkg.jsonfile,vcpkggot confused and terminated the search early.After fixing that the trailing comma, search, install and remove succeeded (however you might want to review the usage string) which contains an unexpanded variable
${GographicLib_LIBRARIES}rather than the usualgeographic::aliases - see below. There are additional details over in the pull request, Thanks for doing this so quickly. Nice job. Attached - fixed json file.John
The package geographiclib:x64-windows provides CMake targets:
On Sun, Jul 12, 2020 at 7:34 AM Charles Karney karney@users.sourceforge.net
wrote:
Last edit: John Coffey 2020-07-13
Charles, looks like the usage string still needs to be addressed, I just tested the latest updates to your pull request which works fine as far as installation goes (search now returns 3 items per your updated vcpkg json file).
geographiclib 1.50.1 a small set of C++ classes for performing conversions between geographic, UTM,...
geographiclib[default-features] Features installed by default
geographiclib[tools] Build the geographiclib tools
However the resulting usage string is still incorrect - maybe like before you need to consider whether it is static or otherwise to give back the correct alias
The package geographiclib:x64-windows provides CMake targets:
FYI the previous one used the following usage
The package geographiclib:x64-linux provides CMake targets:
John
The usage
is what I document on https://geographiclib.sourceforge.io/html/start.html
Please let me know if this doesn't work for you.
The whole point of using the unexpanded variable, is that this form would continue to work as things changed under the hood. (The older documentation is already out of date.) Given that
vcpkgseems to deal with either shared or static libraries (but not both), there's no need to get any more complicated than this. (But the web site does tell you how to select shared/static libraries in more complex setups.)Charles, I am using the ${GeographicLib_LIBRARIES} and although it finds the library, I encountered the following errors associated with one of the tools.
John
How annoying! The problem is that the tools are all registered as targets and the find_package scripts checks that it can the targets are where they are expected to be. But they aren't because they got moved to tools/geographiclib (from tools). I fix. And thanks for catching this.
Please check now. (And thanks for trying this out...!)
That worked!
Thanks
John
On Mon, Jul 13, 2020 at 6:45 PM Charles Karney karney@users.sourceforge.net
wrote:
Charles, I also tried it out on linux and it works there too (defaulting to the static library)
Yes, static libraries seem to be the only (supported) option offered for Linux and MacOS.
I re-checked the Linux vcpkg for GeographicLib and it appears something regressed since the successful linux find_package from my last email 7 days ago.
I don’t usually build on Linux, so when I saw the final merge in vcpkg I thought I would give it a quick try agin. The offending line from my
CMakeLists.txtis shown below:find_package(GeographicLib CONFIG REQUIRED)And here is the corresponding console output:
I suspect a case sensitivity issue, (_find_package) has "GeographicLib" as an argument.
Hope this helps narrow the problem down.
I'm not sure if it is helpful but I did a recursive search for Geographic*
Then I did it for the lower case equivalent
It looks to me like
geographiclibisn't installed on you system.find_package(GeographicLib)should find the config files it need ininstalled/x64-linux/share/geographiclib. What does./vcpkg listreport?You are correct, the package got removed somehow. I suspect it was uninstalled when I ran a command to cleanup my unused packages with a --recurse flag (I was doing a boost cleanup).
BTW I noticed both these entries this in my CMake variable cache, not sure if the
geographiclib_DIRis a leftover vestige.and with more detail...
I'm not sure where the geographiclib_DIR path variable comes from.
John
geographiclib_DIRmight be given because you previously didfind_package (geographiclib)or some such. Try removing the entire contents of your build directory and trying again.