#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