[gdal-dev] Improving GDAL production in our release

[Andrew Bell]

Hi David,

It's not clear what the issues are that you're having. Some specifics
as to the details of your problems would help.

On Mon, Jan 6, 2025 at 6:16 PM David Klaus via gdal-dev
<gdal-dev at lists.osgeo.org> 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
>
>
> 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.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev



-- 
Andrew Bell
andrew.bell.ia at gmail.com