Winelib and static-build

[Alan Nisota]

Boaz Harrosh wrote:
> Dan Kegel wrote:
>   
>> On Sat, Oct 25, 2008 at 8:10 AM, Alan Nisota wrote:
>>     
>>> I can now pass info back and forth between wine and linux via shared memory,
>>>       
>> Sweet!  I had forgotten about /dev/shm.
>>     
>
> If your going the win32 executable way. then do something much easier here.
> Create a winelib (plugin) DLL that exports a stable API to your win32
> application.
>   
If I were to do that, I wouldn't need a win32 executable.  My goal here 
has been to find a way to distribute a binary (for those who don't have 
the means to build it) that will run on as many distributions as 
possible, and building a winelib app basically negates that purpose, 
since I can't build it as a static executable.  This is all related to 
x86-64 as I said before.  The question is:
How do I make a system that has the minimal set of build dependencies 
for the user.  He will need to recompile the host-app (mythtv, mplayer, 
xine) which is enough on a 32-bit platfrom to recompile my app.  On a 
64bit distro, he would need a 32-bit build system, which sets the bar 
much higher.

My current plan is a hybrid approach.  I will support 3 different ways 
to build the program:

a) with the 'loader' code which has no dependency on wine.  I'll stop 
providing the static binary that I've been using fox x86-64.  This will 
be deprecated, and only for those folks who need coreavc but can't 
install Wine for various reasons.
b) as a winelib app which requires a 32bit build env and wine to be 
available.  I won't provide any binaries.  This should be able to build 
on Mac, though I have no way to test it.
c) as a win32 executable (uses mingw to cross-compile).  I'll provide a 
binary executable for those who don't want to build it.  This will only 
work on Linux as it depends on /dev/shm, but will work fine for x86-64.

This should allow the most people to use the code with minimal effort.

> After saying all that. I don't share the wine guys opinion about
> winelib. I think you
> can have a very tight operation with a winelib project. You will see
> that it is very
> easy to package a private copy of wine and with use of a private
> WINEPREFIX in
> scripts you get a nice private operation that is not influenced from any
> wine installation
> in the system.
The problem here is maintenance.  I don't want to have to provide 
packages for every distro under the sun.

It should be noted that my user base is probably less than 50 people, so 
this is not, by any means, a large project.  As such, providing Wine 
would be overkill.  Nearly every distro has a means to install it.

I really appreciate the help I've gotten here.  Thanks.