getting started

[Francois Gouget]

On Tue, 7 Jan 2003, Dimitrie O. Paun wrote:

> On January 7, 2003 03:39 am, Francois Gouget wrote:
> > 1. get the sources to a Linux machine
> > 2. run winemaker on the sources to generate Makefiles
>
> We should modify winemaker to use winegcc. There's now
> a lot of (bad) duplication between winemaker, and winegcc,
> like wrapper support, linking, etc.

Actually there is not all that much duplication and I think winemaker
and winegcc have different purposes:

 * winegcc & co
   The assumption is that the user already has Mingw makefiles that
work. So their goal is simply to emulate the tools that come with the
Mingw environment.

 * winemaker
   The assumption is that you have a Windows application (complete with
CR/LF), most likely based on Visual C++ and thus with no suitable
makefiles. So winemaker's goal is to quickly generate suitable Makefiles
that will build Winelib applications/dlls from what it's given and fix
the simple issues in the source (CR/LF, #pragmas). The backend is
somewhat secondary.


Currently the Makefiles are modelled after the Makefiles used to build
the programs in Wine. From there we can go into two directions for the
backend:
 1. make the Makefiles more similar to those of the Wine programs.
Alexandre told me he wanted the winemaker Makefiles to match and reuse
more stuff from Wine. Part of this goal was to move lots of autoconf
stuff to a .m4 file and to use that in both Wine and Winemaker generated
stuff. There is some work to do there to make this feasible because
Winemaker has to deal with the possibility that there may be multiple
.exe/.dlls to build from a single Makefile (so you cannot define a
single 'MODULE=' variable at the top of the Makefile) whereas this is
never the case in Wine.

 2. we can modify Winemaker to generate Mingw makefiles (does that rule
out using autoconf?) and assume that a 3 line change will turn them into
Winelib makefiles (or the other way around). Actually, has anyone
written a .dsp to Mingw makefile converter?

Potentially we could do both:
 * modify the makefiles in programs/* to use winegcc & co
 * turn these Makefiles into Mingw makefiles
 * make it so as much of this as possible can be shared with Winemaker
 * have Winemaker generate Mingw compatible makefiles based on the model
above


> Moreover, having
> winegcc handle the linking details automatically, we
> (1) shield the users from all that nastiness, and
> (2) retain more freedom on changing things in the build process.

The user is already somewhat shielded from these issues since he does
not have to write the Makefiles. However each time the build process
changes the Makefiles break so if winegcc & co can help with that it
would be nice.

[...]
> My Perl knowledge approaches zero asymptotically, so I can't
> quite do this myself, but I am willing to help on it with
> what's needed.

The problem for me is time :-(


-- 
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
    I haven't lost my mind, it's backed up on tape around here somewhere...