[webkit-dev] OSX: Linking to custom build resorts to system version...

[Nikolay Tsenkov]

What if I rename the framework? Then there should be no collision with a system framework?
Can and how do I do that?


Regards,
Nikolay Tsenkov

> On Nov 29, 2015, at 1:58 PM, Nikolay Tsenkov <nikolay at tsenkov.net> wrote:
> 
> I tried this in a testing project, producing an app with a single window with a webView in it, and it doesn’t work. (setting the env variable in the scheme)
> 
> What’s even worse, I actually need to link to the custom WebKit.framework from a dynamic library, not an executable and I guess even if this works for executable, it will not work for a dynamic library project? (It’s a plugin project and an executable I have no control over will load it)
> 
>> On Nov 29, 2015, at 5:39 AM, Dan Bernstein <mitz at apple.com <mailto:mitz at apple.com>> wrote:
>> 
>> 
>>> On Nov 11, 2015, at 2:06 AM, Nikolay Tsenkov <nikolay at tsenkov.net <mailto:nikolay at tsenkov.net>> wrote:
>>> 
>>> Hello,
>>> 
>>> First of all, thanks for the awesome OSS software that WebKit is!
>>> 
>>> I need some help with linking to a fresh build of WebKit.framework on OS X:
>>>  - I am building a modified version of WebKit.framework (my changes are in WebCore and WebKit projects) on OS X 10.11, but I am not able to use that framework in another project - somehow the project always resorts to the default system WebKit.framework.
>>> 
>>> Setup:
>>>  - OS X 10.11.0 (just saw there is 10.11.1 available, but haven’t installed it yet)
>>>  - System Integrity Protection (SIP) disabled (I couldn’t build when ON)
>>> 
>>> Changes:
>>>  - (Gist) I am making a version of the WebView (the legacy one, the single-process model) which can be used in DAW plugin, exposing API for rendering the audio, settings the sampling rate, not rendering to the audio hardware directly, etc.
>>>  - (Specific)
>>> 	 - (WebCore) -Replaced- AudioDestinationMac with AudioDestinationDaw;
>>> 	 - (WebCore) -Add- DawStateSingleton which exposes the custom destination node to the WebView;
>>> 	 - (WebKit) -Modify- WebView to include a new constructor and couple of new methods:
>>> - (instancetype)initWithFrame:(NSRect)frame samplingRate:(float)samplingRate frameName:(NSString *)frameName groupName:(NSString *)groupName;
>>> - (void)setDawSamplingRate:(float)samplingRate;
>>> - (void)renderAudio:(int) numberOfFrames bufferList:(AudioBufferList*) bufferList;
>>> 
>>> In a new project, I am trying to use the new WebView. If I don’t link to WebKit.framework, of course, the build fails because it can’t find the framework. But if I link to the custom build (the WebView header is the new one, I’ve checked) in run time the app breaks with “-[WebView initWithFrame:samplingRate:frameName:groupName:]: unrecognized selector sent to instance” from which I infer it’s using the system version of the WebView.
>>> 
>>> I’ve tried to inspect how the MiniBrowser project correctly is referring to the new build, but I don’t see how the linking is happening…
>>> 
>>> Could someone help me out with this?
>>> 
>>> Please, accept my apologies, if there is something simple that I’ve missed.
>> 
>> The most common way to get your executable to pick up your custom built WebKit instead of the system WebKit is to have your executable run with the DYLD_FRAMEWORK_PATH environment variable set to the the path where your built frameworks are. The run-webkit-app script in Tools/Scripts does this. Or if you’re running your up from within Xcode you can set the environment variable for the Run action in the scheme editor. There are a few other ways to get the environment variable set, and some other ways to get your program to pick up your framework, but I think the above should give you a good start.
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20151129/01300e47/attachment.html>