#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