This is needed because when clients integrate libmexclass, the client's .dll file has to be in the same folder as the gateway.mexw64 (or the equivalent generated on other platforms) for reasons explained in the Accepted Answerhere.
In such cases, the gateway.mexw64 is usually inside a packaged folder (which ideally should be, to avoid any potential name conflicts), then the gateway() calls in the libmexclass.proxy.Proxy.m would fail for 'gateway' not found.
To work around this, clients will have to update the gateway calls manually to the packaged hierarchy in which the client dll and gateway.mexw64 is placed, say for instance client.cpp.gateway().
To avoid clients having to update the libmexclass.proxy.Proxy.m, every time after they install it, better to have a hardcoded packaged name for gateway, say libmexclass.proxy.gateway and use it in the libmexclass.proxy.Proxy.m.
Thus the only requirement for the clients would be to copy over their dll and gateway.mexw64 (which they already have to do) to the +libmexclass/+proxy folder (where the Proxy.m is also residing) in the final install location.
Consider using a fixed packaged name for the
gateway()
calls inside thelibmexclass.proxy.Proxy.m
.This is needed because when clients integrate
libmexclass
, the client's.dll
file has to be in the same folder as thegateway.mexw64
(or the equivalent generated on other platforms) for reasons explained in the Accepted Answer here.In such cases, the
gateway.mexw64
is usually inside a packaged folder (which ideally should be, to avoid any potential name conflicts), then thegateway()
calls in thelibmexclass.proxy.Proxy.m
would fail for'gateway' not found
. To work around this, clients will have to update thegateway
calls manually to the packaged hierarchy in which the clientdll
andgateway.mexw64
is placed, say for instanceclient.cpp.gateway()
.To avoid clients having to update the
libmexclass.proxy.Proxy.m
, every time after they install it, better to have a hardcoded packaged name forgateway
, saylibmexclass.proxy.gateway
and use it in thelibmexclass.proxy.Proxy.m
. Thus the only requirement for the clients would be to copy over theirdll
andgateway.mexw64
(which they already have to do) to the+libmexclass/+proxy
folder (where theProxy.m
is also residing) in the final install location.