[RFC] Winelib enhancements

[Dimitrie O. Paun]

Folks,

You are probably familiar with the Winelib page:
	http://www.dssd.ca/wine/Winelib-Apps.html
where I describe what one needs to do to compile
a Win32 application under Winelib.

My original motivation for doing the work was to better
understand what inconveniences one has to go through
to do the port, and what we can do to eliminate them.

Here are my thoughts on the subject, in the build order:

Compilation
  This step require the addition of some flags, and the
  potential removal of others. Simple to do, and if there
  is a configure script, quite doable.

  However, these tweaks are really annoying in the initial
  stages of the port, and would be so nice if we had a nice
  compiler wrapper (call it wcc) that would do that behind
  the scenes, so that the only modification to the makefile
  would be:

-CC=gcc
+CC=wcc

  Q: Alexandre, would you accept such a utility in the tree?

Resources
  These ones are nasty. Programs typically use the windres
  compiler that compiles a .rc file into a .o file directly,
  which is later simply linked into the application.
  We go a different route, by sticking the resources in the
  .spec.c files, and this entails non-trivial modifications
  to the makefiles. The ideal option would be to provide a
  windres compatible command line mode for wrc, so that we
  can do:

-RC=windres
+RC=wrc
  
  This would mean moving the resources out of the .spec.c
  file, and exporting the resources variable so we can link
  it into the .spec.c file.

  Q: Alexandre, is this acceptable? Does it warrant discussion?

Linking
  Another tricky step, with multiple problems
  1. We are missing import libraries. As a result, we can not
     link with -lwinspool, we need to link with -lwinspool.drv
     Small change, but it can present nasty problems if you want
     to submit the patch upstream, to the application maintainers.
     I understand this one is already on Alexandre's TODO, so
     we should have a solution to it not before too long.

  2. Our linking process is quite different from the "standard"
     one which uses gcc/ld to do the linking. We generate
     intermediate files (.spec.c files), and use different flags.
     Again, the solution for this (to at least help initial
     porting efforts) would be a wrapper script that does this,
     that can be used instead of ld. And so the question comes
     back again, to haunt us: is this needed/wanted/acceptable?

Running
   This is a new step in the process that we introduce. Currently
   we produce a shared library that requires a wrapper script to
   start it up. Many considers this (and I might say rightfully so)
   ugly/bloat/etc. The ideal situation would be to generate regular
   executables, like all well behaved libraries.

   Here are a few solutions:
   1. An interim step is to improve the wineapploader script so that
      it can be used by all apps. This is a simple thing to do at the
      moment, but does not solve the root cause, it just ease the pain
      a bit. This way you don't need to fight the application 
      maintainers to get such script included in their tree, and having
      to answer the eternal questions: "WTF is this? I thought that
      compiling under Winelib would yield an executable that did not
      need wine. What's the difference as compared to running the Win32
      binary directly?"
 
   2. Fix the build process so that we can actually generate regular
      executables. Thing is, I don't know what's involved in doing so,
      and I'm afraid only Alexandre knows the answer (hint, hint :)).
      So a discussion on this topic is needed, just to figure where
      we want to go from here.

Now, this message is meant to elicit discussion on these topics, so
that at the end of the day I can gather the conclusions, and track 
them on TODO page. So do not hesitate to send in your comments. :)))

Thanks for your attention, and sorry for the long message.

-- 
Dimi.