%% Soren A <[EMAIL PROTECTED]> writes: sa> Yes, this will definitely fix MinGW.
Good, I'm happy then :). sa> I guess that is the part that confused me, indirectly, so to sa> speak. Is there some reason to prefer to use memmove() over sa> bcopy() if both are available? Realistically it probably makes no difference. I suppose there's a hypothetical possibility that memmove() will be performance-tuned on some system, while bcopy() is just a simple loop. But (a) that probably wouldn't matter much to make, and (b) it's pretty unlikely anyway. Stylistically I always prefer to use C standard functions as much as possible. sa> And, if so, why is not memmove() used in the code as a whole (and sa> conversely only gets redefined to bcopy() in <make.h> if the sa> system headers don't already do that)? I am guessing that it's a sa> historical artifact from days when bcopy() was the sa> commonly-available function on the platforms that GNU make found sa> most 'native' and that ISO-ization came later and made memmove() sa> more prevalent? Yes. One of the jobs on the list is to clean this up and change the code to use standard ISO C functions, and define macros for them where they don't exist. Also I want to switch to using ansi2knr, etc. But this is a lot of work and I haven't gotten around to it. sa> However the one case still left unhandled is where HAVE_MEMMOVE sa> won't be defined and bcopy isn't a library function OR a sa> macro. Are we to assume then that such a hypothetical platform is sa> completely broken / insane and not care ;-)? [I am pretty sure the sa> "right" answer is "yes".] Yes :). How can we copy data? I guess we could create our own, but if you don't have those you almost certainly won't have lots of other functions GNU make needs. sa> Right, and my other major change to the package (that is in the sa> present diff patch on my site) is that I use _GNU_ Makefile magic sa> (instead of autoconf) to address that. But I always realized that sa> this was a quick-and-dirty way to get things built because we sa> wouldn't want the source package for 'make' to assume that the sa> user already has GNU make installed Well the GNU standards require that packages not require any special tools. The whole entire point of using automake is to allow packages to ship with makefiles that are 100% portable without having to go through all the effort to write them--which is considerable if you don't use the flexibility of a powerful make program like GNU make. sa> -- users might sometimes have some other (lesser ;-) 'make' sa> installed that they need to build GNU 'make' with. Or not have any make at all. The correct answer to this situation is to use the build.sh shell script to bootstrap make. If you have a shell in MINGW you can use it directly. There's also a Windows .bat file IIRC. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
