Should winemaker be able to handle this

Dimitrie O. Paun dpaun at rogers.com
Fri Apr 2 18:40:06 CST 2004


On April 2, 2004 4:01 pm, Francois Gouget wrote:
> These options are global, i.e. they are supposed to be effective in
> every makefile makefile generated by winemaker. For this reason they
> used to go in the Make.rules.in file. That way one could later modify
> them in one place instead of having to manually edit tens or hundreds of
> makefiles.

OK, so let's look at the problem. We have basically two distinct
use cases here:
    A. We have a .dsp that we can convert to a Makefile
    B. We don't have a .dsp, so we autoguess a Makefile

For (A) to work, we need to integrate the dsp2make, this is in
the works (or at least we plan on doing :)). For this case, we
don't need those options, but rather we need a _reliable_
conversion from .dsp -> Makefile. By reliable I mean that the
result need not be handedited, so that on updates to the .dsp
we can regenerate the Makefile. Moreover, we can not assume
this to be the real project Makefile, we should generate it
in such a way that another GNU Makefile can include it
(using the include GNU extension; other makefile systems
support this extension BTW in some form on another).

For (B), the generation of the Makefile is a one time thing.
After first generation, it should be properly maintained
manually. We can not pretend to autoguess any Makefile right,
but the trivial ones, and encouraging regeneration like this
is just dangerous. So for this case we don't need those
options either, the user can simply edit the resulting Makefile
and add them in there just as easily.

In other words, I think we should get rid of those options
altogether, and focus on supporting the .dsp2make stuff,
this is where the money is.

-- 
Dimi.




More information about the wine-devel mailing list