[gdal-dev] Improving GDAL production in our release

[David Klaus]

All,

I just wanted to follow up on this thread to report how we solved this
issue. Using vcpkg we were able to create a custom build of GDAL 3.10.0
that statically links Proj. We have a new build script using vcpkg. This
seems to have improved our build process, but the proof will be in how easy
it is to build our next GDAL target. Thank you everyone for your help,

On Mon, Jan 6, 2025 at 5:53 PM David Klaus <dklaus at carlsonsw.com> wrote:

> Dear GDAL-DEV Community,
>
> I apologize if this isn’t the right forum for this inquiry. If so, please
> feel free to disregard this email.
>
> *Current Problem:*
>
> I am reaching out for advice on streamlining the process my company uses
> to produce new versions of GDAL for our releases. Currently, we maintain a
> batch file that handles some preliminary setup tasks and then initiates a
> custom GDAL build using CMake. Unfortunately, this process has become
> overly complex and challenging to maintain. Developers find it cumbersome
> and even when the process is followed correctly, it often requires
> additional work for each release. This eats up valuable development time
> and isn't very fun for our developers.
>
> *Why We Build GDAL Ourselves:*
>
> Our program has a number of unique requirements which we haven't been able
> to satisfy through any means besides a custom build. Further we haven't
> found a means of generating a custom build besides what I outlined above. A
> key example of this is our use of the Proj library.
>
> In our builds, we statically link the Proj library into GDAL. This
> approach is necessary because our product integrates with other
> environments that often include their own GDAL builds. In the past,
> dynamically linking the Proj library caused significant issues: these other
> environments would sometimes load their Proj dll in such a way that our
> GDAL would mistake their Proj dll for ours and attempt to use it. This
> mismatch resulted in crashes for our users.
>
> To address this problem and meet our other requirements, we opted for
> custom GDAL builds.
>
> *Any help would be appreciated:*
>
> So, given the challenges of maintaining our current custom build process,
> we are exploring simpler alternatives for producing a GDAL that meets our
> needs. However, our research hasn't yet yielded actionable improvements. We
> would greatly appreciate any advice, recommendations, or insights the
> community can offer that might help.
>
> Thank you for your time and assistance,
>
>
> --
> David Klaus
> Carlson Software
>


-- 
David Klaus
Carlson Software

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250131/31f2641f/attachment.htm>