[MacPorts] #45251: request for lldb

[MacPorts]

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

Comment (by jeremyhu@…):

 Replying to [comment:21 rjvbertin@…]:
 > the only location where we can really codesign from within MacPorts is
 in the (post) activate step.

 I'm not suggesting that you somehow get the macports user to access the
 real user's keychain.  That's not needed to adhoc sign.  Just set
 LLDB_CODESIGN_IDENTITY="-" to get it adhoc signed.

 > >   3. Where is the  code-sign-1.0.tcl that you reference in the
 Portfile changes?
 >
 > Submitted elsewhere, ticket #51504

 > >   4. We should not rebuild everything for lldb.  The cmake build
 system should be capable of building lldb against the installed llvm and
 libclang.  Can you try that out.  There are some reasons why we can't yet
 do that for clang, but it's a goal to not have to rebuild what's already
 built.
 >
 > When I can find a couple of hours I don't need my machine for other
 things ...
 > Note that I build within the lldb subdirectory. CMake's Makefiles are
 clever enough to rebuild only what's absolutely necessary in that case.

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

 > >   5. We should not need to use `install_name_tool` to change the dylib
 identifiers.
 >
 > 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).

 > >   6.  Why patch-accept-build_types.diff?  What's being passed that
 isn't accepted?  Should you instead update that list and push the patch
 upstream?
 >
 > 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.

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