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, chapter 5.
I see that winemaker has changed since then. In particular the bit that is not working for my case is the -D, -I, -L and -l options.
What I want is to run winemaker to generate the build environment and then do the build.
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 -DMY_SETTING -I$MY_INC_DIR -L$MY_LIB_DIR -lmylinuxso .
I see that we don't bother with generating spec files any longer. However I see that the -D, -I, -L and -l options don't find their way into the Makefile these days. Is that by design or a bug? (i.e. do I have to fix winemaker or do I need to look at a different way of doing it)
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 -DMY_SETTING -I$MY_INC_DIR -L$MY_LIB_DIR -lmylinuxso .
I see that we don't bother with generating spec files any longer. However I see that the -D, -I, -L and -l options don't find their way into the Makefile these days. Is that by design or a bug? (i.e. do I have to fix winemaker or do I need to look at a different way of doing it)
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.
But ever since Dimitrie removed autoconf support we don't have a Make.rules.in file anymore and thus are completely ignored.
Maybe we should re-add support for autoconf. Or maybe we should duplicate these settings in every makefile that we generate.
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.
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 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.
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. For instance when I test winemaker on the 'Programming Windows 98' it generates 146 makefiles. Eventhough it's supposed to be a one-time thing (which it has unfortunately not been in the past but hopefully this is behind us now), it's a major pain to go through 146 Makefiles to add/remove some settings that you know are needed everywhere... like -DSTRICT.
Once winemaker gets used on even larger projects, which is the eventual goal, it may end up generating even more Makefiles and the options will be needed to get and initial result that needs as little modification as possible.
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 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.
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
-
Bill Medland -
Boaz Harrosh -
Dimitrie O. Paun -
Francois Gouget