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