#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:20 jeremyhu@…]:
1. Don't skip codesigning. There's not really a reason that I can see to do patch-no-codesign-3.9.diff. If the developer doesn't have a CODESIGN_IDENTITY set, just adhoc sign it by setting LLDB_CODESIGN_IDENTITY to - when executing cmake.
That's what I did at first, but as discussed elsewhere, the only location where we can really codesign from within MacPorts is in the (post) activate step. During the build step where lldb is normally signed, the user is the macports user, who typically won't have access to the *operator*'s keychain (and HOME will be set to point elsewhere anyway). We can of course sign twice, but that would mean using `-f` the 2nd time, and are we sure that will work, what with the kernel caching?
2. We should probably allow users to specifiy a codesigning identity in macports.conf and honor that.
There's a parallel discussion on the devel ML about this.
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.
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?
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. -- Ticket URL: <https://trac.macports.org/ticket/45251#comment:21> MacPorts <https://www.macports.org/> Ports system for macOS