[MacPorts] #45251: request for lldb

MacPorts noreply at macports.org
Fri Sep 9 10:31:02 CEST 2016


#45251: request for lldb
--------------------------+----------------------
  Reporter:  rjvbertin@…  |      Owner:  larryv@…
      Type:  request      |     Status:  assigned
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  lldb         |
--------------------------+----------------------

Comment (by rjvbertin@…):

 Replying to [comment:23 jeremyhu@…]:

 > Ok, that's good enough for now, but we should look into that a bit more.

 I could raise the question on the lldb ML...

 > > Is there a reason why it's necessary for the other subports?
 >
 > It's not.  The other subports don't do it (as of a year or so ago).

 My bad. I introduced the identifier change when I was setting up a variant
 that builds a static libllvm and thus allows to build a redistributable
 libclang. (Potential) ports that provide a clang-based parser could
 benefit from that as they could simply depend on *a* port providing
 libclang, without the need for installing a full clang port or clang-
 version variants. KDevelop is one such port, slated for release in a near
 future along with the other KF5 ports.
 It's been a while, but it looks that the identify change is required to
 make all the libraries load when using KDevelop and NOT using a
 redistributable build.

 The change basically locks the dylibs to their intended location; is there
 anything wrong with that?


 > > That's because of a change I proposed for the CMake portgroup which
 still hasn't been included (or rejected). Using another than the 4
 predefined build types it becomes possible to control the compiler flags
 (upstreams of what the buildsystem might do with them). Debian has a
 similar tactic (-DCMAKE_BUILD_TYPE=Debian), I presume for the same reason.
 >
 > Ok.  Perhaps send this patch upstream to llvm.org then.

 OK, I'll see about that. I have a hunch that "they" will tell me just to
 use one of CMake's predefined types, and that if MacPorts wants better
 control over the compiler options it's their problem ;)

-- 
Ticket URL: <https://trac.macports.org/ticket/45251#comment:24>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list