Dimitrie O. Paun wrote:
Right. We need to support that case, but it seems that we need a way
to include stuff in the generated Makefiles. So, instead of adding all
these options, maybe we can find a way to simply allow the user to
include stuff in the generated Makefile. Something simple, like:
wi
On April 3, 2004 6:43 pm, Francois Gouget wrote:
> I agree on the A/B distinction. However even in the B case we need these
> options for those cases where winemaker generates a whole lot of
> makefiles.
Right. We need to support that case, but it seems that we need a way
to include stuff in the g
On Fri, 2 Apr 2004, Dimitrie O. Paun wrote:
[...]
> 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
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
On Fri, 2 Apr 2004, Bill Medland wrote:
[...]
> What I used toi have was:
> #! /bin/bash
> # Run this script in order to pass the correct arguments to winemaker so that
> # it can set up the build environment
> winemaker --nosource-fix --nogenerated-specs --dll --single-target mytarget
> --nomfc -D
I haven't been following the winemaker stuff so I don't know whether it is
supposed to be able to handle this (and is broken) or not.
I am having to play with the "build a builtin dll to wrap a linux so" concept
again after a year or so since the last time, as discussed in the Winlib
manual, ch