MBS Plugins: Mac OS ones inside Windows Libs folder

Add-Ons
1

When compiling my large complicated app for Win32 builds, I notice a bunch of MBS plugins that look like they are for OS X Cocoa:

MBS_MacOSXCG_CG_Plugin_18715.dll
MBS_MacOSXCF_CFDictionaryArray_Plugin_18715.dll
...

Presumably they are just stubs, but they do add up to ~1MB in size so I’d like to remove them.

I’m pretty sure I have all myplugin-related code blocked out with “#if TargetCocoa” - so I’m wondering if these are due perhaps to me having Module or Window properties that are Cocoa MBS classes? I guess I could remove all the Cocoa MBS plugins, then build for Win32 and see where the errors show up?

Is there an easier way to track these down?

2

Why not just remove those plugins from the plugins folder on Windows?

3

Removing the OS X plugins from the Win32 libs folder and launching the app, gets the dreaded Runtime Error “Can’t find plugin method…” So the DLLs are clearly used in the app somehow.

4

Yeah if you have properties that would refer to OS X portions of the plugin then you’ll get those items included even though your code may not manipulate them at runtime.

Our preferences are a good example of how to avoid this
Instead of properties for Windows, Linux & OS X that we can check we have a single “PropertyProvider” interface that has 3 separate concrete representations - one for each target
Then at runtime we create & assign the property that platform specific instance & everything works and we do not include Windows DLL’s on OS X or Linux, OS X dylibs on Windows or Linux etc

5

And before you suggest “well the compiler should strip this out as its not used” - it is

There will be code that gets sent to the compiler that sets those properties to some initial state.
You don’t write the code BUT the IDE does it for you - because you put those properties on the layout.

I can hear “well the IDE should see that its not used anywhere else and NOT do that”.
It cant see that its not used anywhere until the code is compiled :stuck_out_tongue:
Kind of a catch 22.

Doing something to NOT depend on those properties being directly on the window layout is your best bet.

6

The DLLs are almost certainly empty stubs, but they do need to be there.

7

I know the problem. See blog post:

https://www.mbsplugins.de/archive/2012-07-08/Reducing_app_size_with_

1 Like
8

The key is to have properties being variant and only move them in right typed variables within #if blocks.
Or mark whole classes, windows or modules to be Mac only.

9

ugh - not variants
you lose all kinds of type safety

10

Norman, is there a way to define a property to be Windows only or Mac only?

11

Not in the IDE, but it is possible.

The compatibility selector should probably offer checkboxes for

32 or 64 bit
Project type (Desktop, Web, Console, iOS)
Platform (Mac, Windows, Linux, … iOS?)

This wouldn’t cover all possibilities, but would handle the vast majority.

12

I only see checkboxes for 32/64bit and desktop/web/console/ios.
I don’t see a way for saying Windows only.

Maybe there is an attribute to define?

13

There is no way
Like I said when / if you need platform specific properties the best thing you can do is collect them up into an object that you can have different instances per platform