Well, I’m a bit irked at CMake right now. The PUBLIC_HEADERS for setting
up header files in a macOS framework just blithely flattens the directory
tree, so it doesn’t preserve the include tree structure, which would break
compatibility.
I may come back to this later, when I figure out how to make CMake behave.
In the meantime I’m making other cleanups to structure the tree so that we
won’t have to change stuff all over the place later when we want to do that.
- Garrett
On Wed, Feb 21, 2018 at 12:09 PM Bent Cardan <bent@xxxxxxxxxxxxxxxxxxxx>
wrote:
On Wed, Feb 21, 2018 at 11:44 AM, Garrett D'Amore <garrett@xxxxxxxxxx>
wrote:
deliver the library as a Framework rather than in /usr/local/.
That should be an option you pass outside the default for people on os x
(sorry cant switch to calling it macOS, i still it's called OS X).
That cmake option might be what you had in mind, not sure, but my opinion
we would be defaulting to /usr/local, because for me personally I do most
of my development outside of Xcode despite being on that operating system.
For people using Xcode it would be great so that you could literally
select the framework in Xcode, include the nn header and then start writing
sockets.
Would be especially nice to do that as a drop-in framework for iOS too but
there's enough random socket API gotchas such that iOS lower level doesn't
always map to macOS. Especially for IPC due to file system security.. you
can still do nanomsg IPC in iOS but you'd have to write in a few compiler
#defines and the #include conditions to have straight libnanomsg
interoperability as an iOS framework build.
