Notes
(0030088) David Cole (manager) 2012-07-19 14:22	Resolving as "no change required" because: This is one of the fragilities of BundleUtilities and pushes up against its limitations... One of the underlying assumptions presumed in BundleUtilities is that all executables (things that run and have a known @executable_path value) within the bundle are in the same place relative to the libraries that will be loaded in them. That is, they are all in the "bin" directory, or "Contents", or some known location, such that when you go from that directory to the library directory, you are able to reference it as "@executable_path/../lib/libWhatever.dylib". We can do this because most of the time, BundleUtilities only cares about one executable, and the projects that must have multiple executables are willing to live with the restriction that all of their executables must reside together in "bin", or at least at the same nesting level inside the bundle so that a relative path reference like "@executable_path/../lib" actually gets to the right lib directory inside the bundle no matter what executable the reference is made relative to. This is a restriction / underlying assumption that is key to making the whole fixup process work. In the case of "@loader_path" (which I was hesitant to allow into BundleUtilities in the first place because I predicted that a bug like this would crop up eventually.... :-), there is a problem with this underlying assumption: we do not know (and CANNOT know) at build/install time what library is loading what other library dynamically. You may have multiple loaders (multiple libs that depend on you) -- if so, then which one is loading you right now, and what is the relative path from that one to you? You need that information in order to even express the relationship properly, but in the case of multiple differing loaders, you have multiple values, so which one do you use in which scenario? You could still use BundleUtilities in this situation, if, as with the executables, all such libraries are actually in the same directory within the bundle. I'm sure the problem could be solved, but in my view, it goes beyond the scope of BundleUtilities at that point. Right now, we have a singular map of variables that represents the "fixup structure" of all the libraries and executables inside a bundle. We would need a way to track the multiple possible loaders of all libraries (some of which is only available at runtime, or by programmer designation) and to select one of many fixups to be made, rather than simply having one fixup. If you disagree, and would like to discuss this some more, I would request that the discussion take place on the CMake mailing list, rather than here in the bug tracker. I would not object to having this issue re-opened and to get an actual fix in place for it, but ... it's complicated, testing and validating it is going to be a bear, and doing the work required to make this work well in the general case is not something I can get to in the very near future. I would love to see somebody develop a patch that could handle this situation, but I fear it will be a nasty, hairy one. And I won't accept it into CMake unless a test for it is added as part of the patch.

(0031803) David Cole (manager) 2012-12-03 07:46	Closing resolved issues that have not been updated in more than 4 months.

Issue History
Date Modified	Username	Field	Change
2012-07-19 04:57	Artem Baguinski	New Issue
2012-07-19 14:05	David Cole	Assigned To	=> David Cole
2012-07-19 14:05	David Cole	Status	new => assigned
2012-07-19 14:22	David Cole	Note Added: 0030088
2012-07-19 14:22	David Cole	Status	assigned => resolved
2012-07-19 14:22	David Cole	Resolution	open => no change required
2012-12-03 07:46	David Cole	Note Added: 0031803
2012-12-03 07:46	David Cole	Status	resolved => closed

Relationships