[gdal-dev] Improving GDAL production in our release

[David Klaus]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20250106/224f1ca2/attachment.htm>