Hello Robert, I’ve looked at this myself a few times. Here are some interesting points:
GDAL already supports SWIG bindings. If you are really into Swift, then you could potentially add Swift to SWIG and get support that way. I would not recommend using the C interface. The C interface is already a wrapper around C++. The few times I’ve tried it, I found that some C++ inevitably leaked out. This isn’t a big problem with modern C compilers. But I think it could potentially cause a lot of problems for the Swift C importer. I really don’t think this would yield a high-quality Swift interface. Swift fans would probably not be happy with it. This might be the easiest path to try, however. I agree with Gaige that wrapping C++ code in Objective-C++ is relatively simple. At least, it is simple in concept. It is quite tedious in practice. Each C++ class requires 3 files: a public header, a private header for C++, and an Objective-C++ implementation. This, along with any required Swift customizations in the bridging header, would give you the highest-quality interface. But it is a ton of tedious, albeit simple, work. I have an abandoned side project that uses XQuery to parse the GDAL doxygen XML and emit stub Objective-C++ file triplets for all GDAL classes. They are actually a bit more than stubs, they can pass the parameters through in a method call. I haven’t touched it in a couple of years. It is certainly incomplete. And it's in XQuery, <evil laugh>. But I’ll be happy to send it to you if you want. I think a bigger problem here might be Swift itself. There is a strong social component to the language and its adoption. As a consequence, the language is in a constant state of flux. And this is one of the reasons why I think using the C interface would not be popular in the Swift community. GDAL itself is written in an ancient style of C++. It is radically different than a modern C++ project, such as Boost. If you are into OGR, I recommend taking a look at Boost Geometry to an example of what GDAL written in modern C++ could be like. But Swift isn’t like C++. You can’t use an ancient version of Swift. Modern Xcode will refuse to even look at it. The more you write in Swift, the more you expose yourself to breaking changes in the language itself. I’m not trying to dissuade you here. I’m just suggesting that you be aware of some of these issues. My recommendation would be a new, Objective-C++ bridge interface that provides a greatly simplified, high-level interface to any required GDAL functionality. This is the approach I am taking with some SwiftUI apps I have under development. But this really isn’t a collaborative approach. Each app would have its own, unique needs. John Daniel Etresoft, Inc. > On May 19, 2021, at 10:08 AM, Roberto Arista <[email protected]> wrote: > > Dear gdal-dev list, > I would like to use the GDAL library for a macOS project using the Swift > language. Wrapping a C++ library in Swift is not straightforward at all, and > I could not find a satisfactory solution so far. > > There are a few projects on GitHub: >> https://github.com/optionu/Humboldt >> https://github.com/ranveerm/SwiftGDALProject > but they are either incomplete or outdated > > So, I'll probably have to write the wrapper myself. Before even planning the > work, I have a few questions for the list. My focus will be on the OGR module > of the library. > - From what I've read so far, wrapping a C library in Swift is way easier > than working with C++. I've seen from the docs that GDAL has both C and C++ > APIs. Besides the difference between the two languages, do the APIs offer > different functionalities? > - Is anyone willing to join forces to work on a GDAL wrapper for Swift? Or, > is any expert developer willing to help me writing the wrapper? Of course, I > am going to release the code with an open-source license. > > Best > ––– > Roberto Arista > ಠ_ಠ > ––– > > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
