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@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@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev -- Andrew Bell andrew.bell...@gmail.com _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
