On Tue, 30 May 2023, Howard Butler wrote:
I totally agree that we would need to do some kind of cost/benefit
to see if the complexity is worth the trouble. Our experience with
PDAL is that drivers with hairy external dependencies that are
either closed source or not conveniently distributed are
PDAL had this penalty and then we did some profiling and saw that most of the cost was the dlopen, not the
finding of the plugin via the filesystem. PDAL doesn't have a GDALOpen-like single entry method where drivers
are all expected to be loaded and "tried" sequentially, however. We have a m
> On May 29, 2023, at 5:16 PM, Even Rouault wrote:
> 300 ms to load the 127 plugins on my system, ie each GDAL command line
> invokation will at least take 300 ms, which might be a significant penalty in
> some workflows)
PDAL had this penalty and then we did some profiling and saw that mos
Hi,
>> Obvious candidates for
>> standalone CMake projects would likely be for the few drivers that
>> have proprietary dependencies (ECW, JP2KAK, MrSID, Oracle, ...) and
>> aren't shipped by FOSS binary distributions.
> (I don't follow 'and'; surely no FOSS binary distribution could have an
Even Rouault writes:
some thoughts on the thoughts from a packaging viewpoint.
> - you definitely don't want to build all drivers (that can be built as
> plugins) as plugins. This works (this is actually my dev setup, to
> ensure that the core exports all the symbols needed for drivers
> b
Now that the project has made it to CMake, I wonder if there is enthusiasm to
break apart GDAL's build system to take advantage of its plugin capability in a
default fashion to cut down on the massiveness of our default
stuff-you-actually-want build situation. People rightly complain that
li
> On May 28, 2023, at 5:20 PM, Sean Gillies wrote:
>
> Testing build systems is tough. I know GDAL can't test that all optional
> drivers can be configured and built in isolation. At the same time, profiles
> of drivers between the bare minimum and everything-but-the-kitchen-sink are
> usef
Brad Hards writes:
> On Monday, 29 May 2023 8:20:32 AM AEST Sean Gillies wrote:
>> I resented being told on this list (not by you, Even) that I could
>> take it or leave it with regards to the current build situation.
>
> I assume this is directed at me (since I don't see anyone else on the thre
On Monday, 29 May 2023 8:20:32 AM AEST Sean Gillies wrote:
> I resented being told on this list (not by you, Even) that I could
> take it or leave it with regards to the current build situation.
I assume this is directed at me (since I don't see anyone else on the thread).
I regret that you took
Is MVT really a default driver?
You're right. It isn't. Sorry for the confusion
--
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/
On Sun, May 28, 2023 at 2:14 PM Even Rouault
wrote:
> Hi Sean,
>
>
> Using the CMake files as a source of truth helps. But they don't describe
> everything. For example, they don't explain that GDAL needs libhdf5 to be
> built with special features. That one stumped me for a while. I was seeing
>
Hi Sean,
Using the CMake files as a source of truth helps. But they don't
describe everything. For example, they don't explain that GDAL needs
libhdf5 to be built with special features. That one stumped me for a
while. I was seeing a build message like "HDF5 not detected (found
version 1.12.
Hi Even,
I took better notes during my latest upgrade and wrote them down here:
https://github.com/rasterio/rasterio-wheels/pull/106#issue-1720809259.
Using the CMake files as a source of truth helps. But they don't describe
everything. For example, they don't explain that GDAL needs libhdf5 to b
Hi Sean,
I presume you got this because you defined
OGR_BUILD_OPTIONAL_DRIVERS=OFF which then cause OGR_ENABLE_DRIVER_AVC to
be set to OFF.
We already a quite overwhelming amount of documentation in
https://gdal.org/development/building_from_source.html about all the
existing variables, and
On Saturday, 20 May 2023 9:26:26 AM AEST Sean Gillies wrote:
> Hi all,
>
> I really appreciate the documentation at
> https://gdal.org/development/building_from_source.html. But there are gaps.
> For example, today I ran into
>
> CMake Error at cmake/helpers/GdalDriverHelper.cmake:331 (message):
Hi all,
I really appreciate the documentation at
https://gdal.org/development/building_from_source.html. But there are gaps.
For example, today I ran into
CMake Error at cmake/helpers/GdalDriverHelper.cmake:331 (message):
GDAL_ENABLE_DRIVER_AIGRID cannot be enabled because condition
OGR_ENABLE_DR
16 matches
Mail list logo
