No, I think SupportLibs works correctly. I would need to change all
the install_names and library_name of each dependency if I wanted
to install them anywhere else. This is needed in OSX with dynamic libraries.
While this might be OK if I had all the time in the world to check and debug
this for all dependencies and then every time I upgrade them, I don't have
the time and patience. There is no gain in doing any of this extra work.

As I said before, if anyone wants the job of building OSX installers and
thinks will do it better than what I currently do, by all means, take it up.

I can look into weak linking, that is easy to implement. Not sure if
it works in this case.

Victor

----- Original Message ----- 
From: "Jonatan Liljedahl" 
To: "Developer discussions" 
Sent: Sunday, April 06, 2008 2:55 PM
Subject: Re: [Cs-dev] SupportLibs package


> What version of libjack is in the latest package?
>
> What about this?
> http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html
>
> So it seems it should be possible to use -weak_library jack instead of
> -ljack and it should run properly as long as jack isn't referenced?
>
> (there's no point in using jack if you don't have jackd installed and
> running, including a copy of libjack.dylib in SupportLibs is only a
> workaround to prevent csound from not starting)
>
> Also I fail to see why libsndfile "should" go in /usr/local/lib instead
> of bundled with the CsoundLib framework (in
> CsoundLib.framework/VERSION/Libraries). libsndfile has no connection to
> other apps (like jack does) so it's no problem to bundle libsndfile with
> csound, I would even say it would be the right thing to do.
>
> Wouldn't it be great if the SupportLibs package could be skipped and
> users only had to install the CsoundLib framework?
>
> victor wrote:
>> If users are concerned about this, they can run the Jack installer
>> again after installing Csound, which will reinstall the dylib.
>> But it's not a problem, because the dylibs are likely to be the same
>> as well. And libsndfile should go in /usr/local/lib, not inside the
>> framework.
>>
>> Believe me, I have thought long about this and what we are doing
>> at the moment is the best solution. Also since we released the software
>> in 2006, I have not had a single complaint that Csound installation
>> was breaking a Jack system.
>>
>> Victor
>
> -- 
> /Jonatan         [ http://kymatica.com ]
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Register now and save $200. Hurry, offer ends at 11:59 p.m.,
> Monday, April 7! Use priority code J8TLD2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

victor wrote:
> No, I think SupportLibs works correctly. I would need to change all
> the install_names and library_name of each dependency if I wanted
> to install them anywhere else. This is needed in OSX with dynamic libraries.
> While this might be OK if I had all the time in the world to check and debug
> this for all dependencies and then every time I upgrade them, I don't have
> the time and patience. There is no gain in doing any of this extra work.

I don't know how frameworks work, but I thought that maybe
MyFramework.framework/VERSION/Libraries was included in the DYLD search
path automatically? In that case, wouldn't it just be a matter of
copying them there?

If this works it might actually mean less work for you in the future,
since there would be no need to maintain a SupportLibs package.

Is there a lot of other libs in SupportLibs except libsndfile and libjack?

> As I said before, if anyone wants the job of building OSX installers and
> thinks will do it better than what I currently do, by all means, take it up.

Just to be clear: I'm not saying that someone else should build the OSX
installers. Certainly not me, since I know very little about OSX and
doesn't even own a Mac.

So, sorry if I'm being a pain in the butt. :)

> I can look into weak linking, that is easy to implement. Not sure if
> it works in this case.
> 
> Victor
> 
> ----- Original Message ----- 
> From: "Jonatan Liljedahl" 
> To: "Developer discussions" 
> Sent: Sunday, April 06, 2008 2:55 PM
> Subject: Re: [Cs-dev] SupportLibs package
> 
> 
>> What version of libjack is in the latest package?
>>
>> What about this?
>> http://developer.apple.com/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html
>>
>> So it seems it should be possible to use -weak_library jack instead of
>> -ljack and it should run properly as long as jack isn't referenced?
>>
>> (there's no point in using jack if you don't have jackd installed and
>> running, including a copy of libjack.dylib in SupportLibs is only a
>> workaround to prevent csound from not starting)
>>
>> Also I fail to see why libsndfile "should" go in /usr/local/lib instead
>> of bundled with the CsoundLib framework (in
>> CsoundLib.framework/VERSION/Libraries). libsndfile has no connection to
>> other apps (like jack does) so it's no problem to bundle libsndfile with
>> csound, I would even say it would be the right thing to do.
>>
>> Wouldn't it be great if the SupportLibs package could be skipped and
>> users only had to install the CsoundLib framework?
>>
>> victor wrote:
>>> If users are concerned about this, they can run the Jack installer
>>> again after installing Csound, which will reinstall the dylib.
>>> But it's not a problem, because the dylibs are likely to be the same
>>> as well. And libsndfile should go in /usr/local/lib, not inside the
>>> framework.
>>>
>>> Believe me, I have thought long about this and what we are doing
>>> at the moment is the best solution. Also since we released the software
>>> in 2006, I have not had a single complaint that Csound installation
>>> was breaking a Jack system.
>>>
>>> Victor
>> -- 
>> /Jonatan         [ http://kymatica.com ]
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Register now and save $200. Hurry, offer ends at 11:59 p.m.,
>> Monday, April 7! Use priority code J8TLD2.
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Register now and save $200. Hurry, offer ends at 11:59 p.m., 
> Monday, April 7! Use priority code J8TLD2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Register now and save $200. Hurry, offer ends at 11:59 p.m., 
Monday, April 7! Use priority code J8TLD2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net