[PROJ] PROJ 9.6.0RC2

[Even Rouault]

Roger,

good catch. Thanks for your patient testing. I could reproduce on a 
fresh build directory when BUILD_SHARED_LIBS was not set at all. There 
was an ordering issue between setting the default value of 
BUILD_SHARED_LIBS and EMBED_RESOURCE_FILES that led EMBED_RESOURCE_FILES 
to be set to ON in that situation.

Fixed per https://github.com/OSGeo/PROJ/pull/4422

Even

Le 12/03/2025 à 20:36, Roger Bivand a écrit :
> On Wed, 12 Mar 2025, Roger Bivand wrote:
>
>> On Wed, 12 Mar 2025, Even Rouault wrote:
>>
>>>  ok, on second thought, I figured the issue. I assume you have 
>>> statically
>>>  linked PROJ or have explicitly enabled EMBED_RESOURCE_FILES=ON when
>>>  building it (cf
>>>  https://proj.org/en/latest/install.html#cmdoption-arg-EMBED_RESOURCE_FILES). 
>>>
>>>  At least I can reproduce those test failures with 
>>> EMBED_RESOURCE_FILES=ON.
>>
>> In proj-9.6.0/build/CMakeCache.txt created by naked cmake .., I see:
>>
>> //Whether resource files (limited to proj.db) should be embedded
>> // into the PROJ library
>> EMBED_RESOURCE_FILES:BOOL=ON
>>
>> //Whether the PROJ_DATA_PATH should be embedded
>> EMBED_PROJ_DATA_PATH:BOOL=ON
>>
>> //Directory that contains .tif, .json or .pol files to embed into
>> // libproj
>> EMBED_RESOURCE_DIRECTORY:PATH=
>>
>> //Whether embedded resource files (limited to proj.db) should be
>> // used (should nominally be used together with EMBED_RESOURCE_FILES=ON,
>> // otherwise this will result in non-functional builds)
>> USE_ONLY_EMBEDDED_RESOURCE_FILES:BOOL=OFF
>>
>> and lib contains only libproj.so.25.9.6.0 and its links, so not a 
>> static build.
>
> lib/libproj.so.25.9.6.0 is 14.9 MB
>
>> How did EMBED_RESOURCE_FILES get turned on by default, but with 
>> USE_ONLY_EMBEDDED_RESOURCE_FILES off?
>>
>> but no EMBED_RESOURCE_FILES entry at all in 9.5.1, which only has
>>
>> //Whether the PROJ_DATA_PATH should be embedded
>> EMBED_PROJ_DATA_PATH:BOOL=ON
>>
>> Trying again with 9.6.0 and
>>
>> cmake -DEMBED_RESOURCE_FILES=OFF ..
>>
>> gives
>>
>> //Whether resource files (limited to proj.db) should be embedded
>> // into the PROJ library
>> EMBED_RESOURCE_FILES:BOOL=OFF
>>
>> so trying to re-build everything - I don't use ccache, and am using 
>> separate build directories, it'll take a little while.
>>
>
> lib/libproj.so.25.9.6.0 is 5.4 MB
>
> Now rebuilding GDAL ...
>
>> Roger
>>
>>
>>
>>>  Those tests aren't compatible with that configuration of PROJ. 
>>> Ideally we
>>>  should have some mechanism to skip them, but that would require 
>>> that PROJ
>>>  exposes how it has been built. In any case, this isn't something to 
>>> worry
>>>  about, just a testing issue.
>>>
>>>  Le 12/03/2025 à 18:53, Roger Bivand a écrit :
>>>>   On Wed, 12 Mar 2025, Even Rouault wrote:
>>>>
>>>>>
>>>>>   Le 12/03/2025 à 18:07, Roger Bivand a écrit :
>>>>>>    On Wed, 12 Mar 2025, Even Rouault wrote:
>>>>>>
>>>>>>>
>>>>>>>>     unset PROJ_LIB ; ctest for example. Should I add the complete
>>>>>>>>   output
>>>>>>>>   of
>>>>>>>>     running ctest to this thread (490 lines)?
>>>>>>>
>>>>>>>    maybe paste it some paste service (github gist, etc) and link 
>>>>>>> it to
>>>>>>>   it.
>>>>>>>
>>>>>>
>>>>>>  https://gist.github.com/rsbivand/09bd9e998889a44d2eecbb842c1a5168
>>>>>   sorry, no clue. I doubt this is 9.6.0 related
>>>>
>>>>   There are no such errors with PROJ 9.5.1 and GDAL 3.10.2 on the same
>>>>   platform, so the only obvious change is building GDAL with 9.5.1 or
>>>>   9.6.0RC2. That is why I waited, as the airport internet I was 
>>>> depending
>>>>   on
>>>>   before I got to my desktop could have been a factor. For 9.5.1:
>>>>
>>>>         Start 35: test-osr-set-proj-search-paths
>>>>   35/46 Test #35: test-osr-set-proj-search-paths ... Passed 0.12 sec
>>>>         Start 40: autotest_gdrivers
>>>>   40/46 Test #40: autotest_gdrivers ................ Passed 125.56 sec
>>>>         Start 43: autotest_osr
>>>>   43/46 Test #43: autotest_osr ..................... Passed 4.14 sec
>>>>
>>>>
>>>>   Roger
>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.