Re: CVS psmith make: Whoops; configure wasn't looking for memmove.

[Paul D. Smith]

%% Soren A <address@hidden> 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 <address@hidden>          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