Hi, On Tue, Dec 07, 2004 at 06:15:39AM -0800, Jon Griffiths wrote:
Hi,
On the suspicion that my hacking on header files was causing too many files to be rebuilt, I whipped up a quick perl script to identify unneeded header files. This series of patches is the result. Nice stuff, but... where is it? The most important part, I mean: the perl script ;-)
Note that some removed include files might be needed for different systems, so some breakage might/may/will follow this patch. (Gerald Pfeifer will *love* your "nice" work, I'm sure ;-) But I'd still vote strongly for including it, since it will remove lots of cruft. Thanks, Andreas Mohr
Hi, --- Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote:
Note that some removed include files might be needed for different systems, so some breakage might/may/will follow this patch.
I deliberately made my script remove only Wines own headers for this reason. It will not remove system header files. I also manually checked that nothing within an #ifdef block was deleted. So this shouldn't cause any problems for other *nices. If there is an issue it will be with mingw or VC++. But that would point out an incompatability in our headers with theirs, and that would be a good thing, IMHO.
(Gerald Pfeifer will *love* your "nice" work, I'm sure ;-)
I'm happy if Gerald wants to try the patches for beakage before they are committed...
But I'd still vote strongly for including it, since it will remove lots of cruft.
Yes, its a little crufty as-is. My reasoning is that anything that reduces my compile times after updates is good, and my laptop takes quite a while to rebuild Wine, Minimising dependencies helps that. On a related note, would anyone object to a patch that auto-split config.h into multiple files during the build process, and changing makedep to generate dependencies only on the generated config-value file? This would be a big win whenever config.h changes. Currently when config.h changes, 980 files are rebuilt. Using a smarter method would only rebuild the files that depend on the HAVE_ option that was changed (which is bound to be a significantly smaller number). The Linux kernel process does this already, check out /usr/src/linux/Documentation/smart-config.txt for details. Thoughts? Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com
Jon Griffiths wrote:
Hi,
--- Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote:
Note that some removed include files might be needed for different systems, so some breakage might/may/will follow this patch.
I deliberately made my script remove only Wines own headers for this reason. It will not remove system header files. I also manually checked that nothing within an #ifdef block was deleted. So this shouldn't cause any problems for other *nices.
Do the patches take into account that a header might only be included to check that an exported function matches the declaration in the header file? Rob
Hi Rob,
Do the patches take into account that a header might only be included to check that an exported function matches the declaration in the header file?
No, I dont think that case can exist. Each .c file contains 5-20 or more functions that take flags/structs etc defined in the header. The same header defines the function too, so I don't think you'll see this case in practice. However I will knock up a script to check that every function does include the header that defines it, an submit a patch for any cases that turn up (although I don't think there will be any). Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail
Hi,
Do the patches take into account that a header might only be included to check that an exported function matches the declaration in the header file?
I've extended my script to handle this case. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? All your favorites on one personal page � Try My Yahoo! http://my.yahoo.com
Jon Griffiths wrote: [Snip]
Yes, its a little crufty as-is. My reasoning is that anything that reduces my compile times after updates is good, and my laptop takes quite a while to rebuild Wine, Minimising dependencies helps that.
On a related note, would anyone object to a patch that auto-split config.h into multiple files during the build process, and changing makedep to generate dependencies only on the generated config-value file?
This would be a big win whenever config.h changes. Currently when config.h changes, 980 files are rebuilt. Using a smarter method would only rebuild the files that depend on the HAVE_ option that was changed (which is bound to be a significantly smaller number).
The Linux kernel process does this already, check out /usr/src/linux/Documentation/smart-config.txt for details.
Thoughts?
Considering that it takes 6-8 hours to compile on my poor old machine I would appreciate anything that would speed up the process. I dread having to do a ./configure. I know you guy's with your multi GHz machines might say so what, but it would increase your productivity too. Also before you laugh at my machine. One of the primary reasons for me to use this machine is that there lots of these older machines out there (peticularly in the developing world) and I think wine should be useable on anything that it can. -- Tony lambregts and around and around
Hi, On Tue, Dec 07, 2004 at 01:20:57PM -0700, tony_lambregts(a)telusplanet.net wrote:
Considering that it takes 6-8 hours to compile on my poor old machine I would appreciate anything that would speed up the process. I dread having to do a ./configure. I know you guy's with your multi GHz machines might say so what, but it would increase your productivity too. And what about gcc 3.4.x precompiled headers? That should also be a worthwhile target, considering that (as I mentioned before) I managed to hit a tenfold compile performance with my program.
Also before you laugh at my machine. One of the primary reasons for me to use this machine is that there lots of these older machines out there (peticularly in the developing world) and I think wine should be useable on anything that it can. Indeed! I loathe bloatware! Anything that can be done to reduce wait times and memory footprint is a very good thing.
Andreas Mohr
participants (6)
-
Andreas Mohr -
Dimitrie O. Paun -
Jon Griffiths -
Robert Reif -
Robert Shearman -
tony_lambregts＠telusplanet.net