|
Notes |
|
|
(0018978)
|
|
David Cole
|
|
2009-12-22 12:18
|
|
I don't think fixup_bundle should adjust permissions at all.
You could add an install rule that copies this particular *.dylib into the bundle *before* calling fixup_bundle. As part of that install rule, you can set the permissions yourself.
I think this is a useful error that should cause the developer of the application to say to himself... "hey, I'm including a MacPorts built libcrypto inside my bundle... is that really what I want to do or is this just a mistake...?" Then the developer has to make the conscious decision to either allow this to happen (and adjust permissions himself), or eliminate the dependency, or require his end users to install the MacPorts libcrypto, or ...
If you disagree, please elaborate further in another note.
Perhaps attach a suggested patch if you really feel strongly that cmake should handle this for you.
Otherwise, if there's no more activity on this issue, I will resolve it as "won't fix" in about a week or so. |
|
|
|
(0019492)
|
|
Mike McQuaid
|
|
2010-02-09 06:05
|
|
I agree with pvanek on this. I think if you want to be extra safe you could perhaps require an extra variable to be set before running fixup_bundle? Does that sound like a reasonable compromise?
If it does and a patch would be accepted, I'll get to work on writing one. |
|
|
|
(0020376)
|
|
kentwilliams
|
|
2010-04-23 12:53
|
|
David Cole is of the opinion this error is useful in the context of fixup_bundle.
Maybe so, but it's a PITA. If you're building the library that's getting copied as part of fixup_bundle, and the permissions don't allow RPATH_REMOVE to work, you're dead in the water until you figure out how to add an install step to move the file and change the permissions.
I'm dealing with it by adding a custom ExternalProject step to adjust perms after the install. Just getting that right was a whole other story...
I guess my question is this: If a CMake build system includes calls to FILE(RPATH_REMOVE) shouldn't it change permissions to allow that to complete?
If you do this then it will 'just work' -- if you don't work, then there needs to be a better error message from RPATH_REMOVE. |
|
|
|
(0021728)
|
|
Mike McQuaid
|
|
2010-08-12 09:09
|
|
Patch created and added. This adds a variable named "chmod_bundle_items" which will set items as writable before install_name_tool is run on them but after copying.
I'd still strongly argue this makes far more sense to not be optional but default as the variable isn't terribly discoverable and people are likely to just assume fixup_bundle doesn't work otherwise.
If you're making the argument that perhaps people should think about the MacPorts case rather than shipping them accidentally then you should write a better error handling rather than just allowing the install_name_tool command to fail. |
|
|
|
(0021789)
|
|
David Cole
|
|
2010-08-18 00:08
|
|
|
I'd be happy to take a look at your patch... but you're going to have to attach it first. :-) |
|
|
|
(0021797)
|
|
Mike McQuaid
|
|
2010-08-18 04:19
|
|
|
Sorry, thought I'd attached it. It's there now. |
|
|
|
(0022122)
|
|
David Cole
|
|
2010-09-07 22:55
|
|
|
0001-Add-support-for-making-bundle-items-writable-before-.patch (1,668) 2010-08-18 04:18