Probably a good idea overall. I don't know how good CMake's support of
frameworks is though; have you done any testing? I'm mainly thinking about how
well it handles new versions of the same library (Frameworks should handle that
transparently), and anything else that frameworks support (been a while since I
made a framework, so I don't know if anything new/interesting has been added
since the last time I messed with them).
The only issue I can think of is for consumers of nng; they'll have to make
their own build scripts aware that OS X (and iOS, etc.) are special, so they
need to use special flags to compile on those platforms. Some build systems
handle this transparently, others don't. For developers this is irritating,
but for those that only know './configure; make ; make install', this could be
a problem.
Thanks,
Cem Karan
________________________________
From: nanomsg-bounce@xxxxxxxxxxxxx [nanomsg-bounce@xxxxxxxxxxxxx] on behalf of
Garrett D'Amore [garrett@xxxxxxxxxx]
Sent: Wednesday, February 21, 2018 2:44 PM
To: nanomsg@xxxxxxxxxxxxx
Subject: [Non-DoD Source] [nanomsg] macOS developers out there? Or CMake
wizards?
So for nng, I’m considering changing the CMake tree somewhat — my goal is to
make it easier for developers and other projects to consume and use the project.
One of the ideas in this is to use (on macOS) the Framework support in CMake,
so we deliver the library as a Framework rather than in /usr/local/. Are
there opinions from macOS developers in the crowd? Good idea? Terrible idea?
I’m also planning to make this more usable in CMake trees, but using the EXPORT
capability of CMake.
One thing I’m also looking at is to clean up some of the complexity by using
some facilities available in newer CMake (for example I might use capabilities
that only exist in CMake 3.8 — although I need to see how much a PITA that is
going to be for use with CI providers. CMake 3.8 is available since last
April.).
- Garrett
