Should winemaker be able to handle this

[Boaz Harrosh]

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