On Tue, 7 Jan 2003, Dimitrie O. Paun wrote:
On January 7, 2003 03:39 am, Francois Gouget wrote:
- get the sources to a Linux machine
- 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 :-(