[nanomsg] Re: macOS developers out there? Or CMake wizards?

  • From: Bent Cardan <bent@xxxxxxxxxxxxxxxxxxxx>
  • To: Nanomsg <nanomsg@xxxxxxxxxxxxx>
  • Date: Wed, 21 Feb 2018 23:27:05 -0800

yes directories are obviously just files, that's not important,

what is here is that CMAKE was deliberately designed to get disoriented on
the system

so we have to specify `find_path()` for where to look for headers

On Wed, Feb 21, 2018 at 11:05 PM, Bent Cardan <bent@xxxxxxxxxxxxxxxxxxxx>
wrote:

so you're saying forward slashes are special in CMAKE? They are somehow
not just part of a flat unix pathname? I thought UNIX directories are just
files

On Wed, Feb 21, 2018 at 10:50 PM, Garrett D'Amore <garrett@xxxxxxxxxx>
wrote:

no this is strictly a header file issue.
On Wed, Feb 21, 2018 at 10:46 PM Bent Cardan <bent@xxxxxxxxxxxxxxxxxxxx>
wrote:

hmm, I bet it's that CMAKE_INSTALL_RPATH_USE_LINK_PATH variable in the
nng/cmakelist file, which we might be able to overwrite later for OSX using
CMAKE_MACOSX_RPATH

also my gut tells me dont force rpath based on whatever happens to be
the random link path... and honestly the only reason i'm even saying this
is because INSTALL_RPATH sounds totally framework-y..

On Wed, Feb 21, 2018 at 6:09 PM, Garrett D'Amore <garrett@xxxxxxxxxx>
wrote:

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.




Other related posts: