@Evan > the C API is what is commonly used to create bindings to other languages Good to know, thanks!
@Gaige > Also, if necessary, wrapping a C++ library in Objective-C(++) is relatively > simple and I’ve found that effective where I needed to use the more advanced > features (as Even points out, this has been very infrequent). I have almost no experience in writing ObjC, the only experience I have is through the python PyObjC wrapper. I don’t really know if it makes sense for my project. > I’m not sure how much time I have to commit to assisting with the swift > wrapper, but I’m happy to act as a sounding board and help where I have time. Thanks, I appreciate it @John: thanks for sharing your experience! > 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. Considered my level of experience with this technological stack, tedious and simple could work. But I first need to understand if it is worth the effort. > 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. That would be great, so I could get a better sense of how this double wrapper should work. Best ––– Roberto Arista ಠ_ಠ ––– Mobile: +39 366 4537413 ––– > On 20 May 2021, at 00:44, John Daniel <[email protected]> wrote: > > 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
