Re: Re[2]: Using a dylib without installing it
Re: Re[2]: Using a dylib without installing it
- Subject: Re: Re[2]: Using a dylib without installing it
- From: Greg Guerin <email@hidden>
- Date: Wed, 11 Jul 2007 17:17:16 -0700
DAS Loop wrote:
>Now that we don't have a good solution let me introduce another, related,
>problem: My product has two versions: a GUI and a GUI-less one. The GUI
>version is on a bundle, the GUI-less is a non-bundle application that will
>be on, for example, /usr/local/bin .
>They share a lot of libraries and frameworks.
Are they always installed together? Or can a user install one or the
other, then come back later and install the other one, or even install the
uninstalled one from the installed one. I.e. if the GUI version is
installed, but the GUI-less one isn't, can the user install the GUI-less
one by running the GUI one and clicking a builtin "Install" button
somewhere?
>So far I can solve the bundle problem using the install_name_tool but what
>about the other application that is not in a bundle?
If the GUI-less app is always installed with the GUI app, or can be
installed from the GUI app, then you could write a symlink in
/usr/local/bin that points to the GUI-less executable embedded in the
GUI-app's bundle. The embedded GUI-less executable can then refer to the
common dylibs using @loader_path or @executable_path.
This would make the GUI-less version in /usr/local/bin dependent on the
GUI-version's absolute location. You might not want that.
If it's a problem, install the common libraries in a support folder, e.g.
/Library/Application Support/ and have both your GUI app and GUI-less app
refer to them there using an absolute pathname reference in the respective
executable. The libs themselves can refer to one other with @loader_path
or with absolute pathnames.
Or you can install the common libs as your own framework in
/Library/Frameworks. Or in ~/Library/Frameworks. Or as dylibs in
/usr/local/lib.
There are probably many more roughly similar ways of structuring the
relationship between your GUI app, the GUI-less app, and the common
libraries. It just doesn't seem like a difficult problem to me, at least
not for technical reasons.
It could be difficult to decide which approach would be best, based on
one's requirements. Without clear requirements, all the outlined
approaches seem about the same. Given some clear requirements, one or
another might emerge as optimal.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden