[gdal-dev] proj.db and other resource files when building with vcpkg

Even Rouault even.rouault at spatialys.com
Tue Oct 29 04:33:44 PDT 2024


Thomas,

(that would be more a question for the proj-dev mailing list)

quickly looking at the vcpkg PROJ recipe at 
https://github.com/microsoft/vcpkg/tree/master/ports/proj I don't see 
they do anything particular related to automated setting PROJ_DATA 
(PROJ_LIB is now a deprecated name), so you likely have to do it now . 
(conda-forge builds use a trick where upon installation the hard-coded 
path within the PROJ library is modified to match the location of your 
conda environment)

The good news is that in PROJ 9.6, packagers will be able to build PROJ 
with proj.db embedded in the library, using the new capabilities offered 
by https://proj.org/en/latest/community/rfc/rfc-8.html

Even

Le 29/10/2024 à 12:25, Thomas Sevaldrud via gdal-dev a écrit :
> Hi,
>
> We are using gdal/proj through vcpkg, specifically the projections 
> framework with OGRSpatialReference,  and everything builds nicely, but 
> when running our application we get errors related to missing proj.db.
>
> Now, I understand that we can fix it by setting the PROJ_LIB 
> environment variable or copying files to a suitable path. What I am 
> wondering is if this shouldn't already be handled by CMake or VCPKG, 
> is there some step I am missing here?
>
> The resource files can be found in the build directory under  
> "vcpkg_installed/[triplet]/share/proj" so I can do some post-build 
> stuff to copy files into the app output directory, but before I start 
> going that route I'd like to know if this is the way to do it. I would 
> guess that all users of the vcpkg gdal package will run into this issue?
>
> Cheers,
> Thomas
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.



More information about the gdal-dev mailing list