Should winemaker be able to handle this
Boaz Harrosh
boaz at hishome.net
Mon Apr 5 05:17:38 CDT 2004
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:
>
>winemaker -A 'DEFS=-DSTRICT ...'
>
>where -A will simply add the argument as a line at the beginning of
>the generated Makefile. This is easier to implement, document, etc.,
>and it's general enough that we don't have to keep adding options
>to support all sorts of users.
>
>
>
Better yet use include ...
Work out the top-most Makefile directory and have a user.Makefile or
something, than have that included in all generated Makefiles working
out the proper relative path.
Included is a small set of makefiles I use. It is highly specific for
use with MFC and ATL (& STLPort). And it is using gcc strait but maybe
it will give you some Ideas. I did it this way because I needed a way to
have complete control over a big set of make files. Any porting Job will
be the same. Running winemaker over and over is not a solution.
By the way it is all originated from the makefiles Winemaker did (10
month ago) you can see that in base.Makefile .
Some comments.
- base.Makefile is the wine stuff so basically only this file has to
change for adoption of winegcc
- using.Makefile is the big stuff with the libs that all are using (mfc,
atl, STLPort) and common options. You can see in there comments for use
of static lib or dynamic lib. I did not Yet work out a nice way to have
these optional. I think I know how to do it with make. have different
targets and Just change the default. But I didn't work that out Yet.
Also in this file are the root paths to every thing.
- winecpplib.Makefile & wineexe.Makefile are the actual way to do the
thing. keeping it outside like this was a Life saver that I regret I did
not do it much much earlier. This will have to be adapted to winegcc.
Well Just my two cent. This is far from complete:
- No auto dependency (make depend)
- No separate folders for different targets. No debug/release
- No separate file for compiler switches that if changed will cause all
dependent objects to compile.
- No support for all kind of wine targets.
I do think that it is pretty simple. and could be even cleaner and
simpler yet.
I like the "keep real.Makefile in a separate file. And have a delegating
Makefile." It lets you experiment in a way that does not break CVS all
that much.
Also Look in DemoExe. you can see I have separated the files.Makefile to
an outside file. This could be good for Winemaker. Since all other files
are constant. Only generated file is this one. It could be best if
constant set of files are kept out side of Winemaker source and user can
have a command line option to state an alternative path to take the set
of makefiles from. This way you can do specialized projects. Some use
MFC other use something else.
Free life
Boaz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: demomake.tar.gz
Type: application/x-gzip
Size: 4550 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20040405/883838ba/demomake.tar.bin
More information about the wine-devel
mailing list