Re: Make configuration for Win32.

[Soren A]

Soren A <address@hidden> wrote in
news:address@hidden: 

> "Paul D. Smith" <psmith=mXXj517/address@hidden> wrote in
> news:15740.32132.493047.72085=Xa+LbO3DC1G7dXONAhJuzGpMazypIftMhCv4THm1bD
> address@hidden: 
> 
>> For bcopy etc., the configure script checks that these exist and, if
>> not, redefines them using ISO C functions (see make.h). 
> 
> I don't require a reply, Paul, -- I don't want to seem lazy and the
> proper non-lazy thing for me to do (which for reasons other than sheer
> laziness I am inhibited from doing in my present setup right now, for a
> little longer) would be to check out the CVS sources and check
> change-logs myself. 
> 
> But: as of make-3.80rc1, this wasn't true: checking for bcopy() wasn't
> happening. Nor for memmove(). I posted about that in another message
> tonight and so I am mentioning it here (I read the other message and
> replied before finding and reading this thread). So if make's source
> build-configuration IS checking for bcopy() now, it's a recent
> addition? 

In an attempt to wrap up the potential confusion I may have generated in 
this thread in this|ese List|s, I am going to copy here the final results 
of discussion with Paul Smith in which he is at last successful in getting 
me to understand how this problem is now fixed for MinGW. For the record.
------------------------------------------------------------------------
Subject: Re: CVS psmith make: Whoops; configure wasn't looking for memmove.
Date: Tue, 10 Sep 2002 16:56:02 -0400

I am freed from the vile wilderness of Confusion at last ...

"Paul D. Smith" <address@hidden> wrote in
news:address@hidden: 

> %% Soren A <address@hidden> writes:
> 
>  >> I don't understand this.  If bcopy() isn't there and memmove() is
>  >> (which wasn't being checked but now will be) then the code in
>  >> make.h as-is works.
>  >> 
>  >> Doesn't it?
> 
>   sa> It really doesn't. [...]
> 
> Please note my parenthetical statement (also the message in the thread
> which you replied to): in the code you started with, there was a
> missing configure script check for memmove().
> 
> Because of that, no matter whether or not there was a memmove() on the
> system, the HAVE_MEMMOVE constant would _never_ be defined.
> 
> This is obviously a bug and this is what I fixed in the CVS commit
> which started this thread. 

Yes, agreed, I now understand why this was a thing that had to be fixed.

> After this fix MINGW systems, which do have memmove(), will define the
> HAVE_MEMMOVE macro.
> And as you've stated, bcopy() is not defined on MINGW.
> 
> In that case, the original test:
> 
>   # if defined(HAVE_MEMMOVE) && !defined(bcopy)
> 
> will be true and bcopy() will be translated into memmove().  Which is
> what you want. 

Yes, this will definitely fix MinGW.

{snip}
> Now consider a platform on which there is a bcopy() and no memmove().
> Then we will not define any macros, and we will invoke bcopy()
> directly.
> 
> Up until now, our two solutions are identical (with the caveat below
> regarding the "weird case").
> 
> However, here is where they are different:
> 
> Suppose a platform has _BOTH_ bcopy() and memmove() functions.  Then,
> my solution will prefer the memmove() solution (that is, it will
> define bcopy() as a macro expanding to memmove()).  Your solution will
> prefer the bcopy() solution (since HAVE_BCOPY will be true) and use
> the bcopy() function without any macro.  That's all I meant. 

I guess that is the part that confused me, indirectly, so to speak. Is
there some reason to prefer to use memmove() over bcopy() if both are
available? And, if so, why is not memmove() used in the code as a whole
(and conversely only gets redefined to bcopy() in <make.h> if the system
headers don't already do that)? I am guessing that it's a historical
artifact from days when bcopy() was the commonly-available function on
the platforms that GNU make found most 'native' and that ISO-ization came
later and made memmove() more prevalent? Perhaps that's a question you
should feel free to ignore if time-constrained since it's obviously only
of minor historical interest if I am at all right. 

My main problem seems to have been that I got fixated somehow on the test
for bcopy() and couldn't get past that ;-). I didn't realize that a large
number of platforms take care of bcopy() in the headers by defining it as
a macro. My eyes don't parse lower-case macro identifiers very well --
it's inexperience. Initially, I WAS misreading the macro in question. 

>   sa> The new macro statement says, to me: "if *configure* finds that
>   sa> bcopy() is not present, then define bcopy() as a macro that
>   sa> resolves to a call to memmove() [with the function parameters
>   sa> suitably rearranged]." My change doesn't prefer bcopy(), it
>   sa> defines bcopy() as a macro that resolves to memmove().
> 
> Yes, but as I show above your change prefers bcopy() in the case where
> both exist (if only one exists it doesn't make sense to talk about
> "preferring" one: if there is only one choice then the other choice is
> an error). 

My apologies for being too dense to see that.

{snip}
> As I mention above, there are other header files included, namely the
> system header files like memory.h or stdlib.h or whatever.
> 
> It's the case where _THESE_ system header files define bcopy() as a
> macro that the test is guarding against. 

I did get that last round but still couldn't pull it all together in my
mind. However the one case still left unhandled is where HAVE_MEMMOVE
won't be defined and bcopy isn't a library function OR a macro. Are we to
assume then that such a hypothetical platform is completely broken /
insane and not care ;-)? [I am pretty sure the "right" answer is "yes".] 

{snip}
> I believe that if you pull the CVS sources (or wait a day or so for the
> next rc build) you will find that you will not have this problem any
> longer.  If you still do there is something deeply strange going on. 

{snip}
> I've no doubt whatsoever that there are whole classes of problems
> waiting to be discovered.  The autoconfiscation of GNU make has never
> even _considered_ the needs of a Windows platform.
> 
> As was pointed out a few times, it's pretty obvious when you consider
> that there isn't any configure support anywhere for the code in the w32
> subdirectory. 

Right, and my other major change to the package (that is in the present
diff patch on my site) is that I use _GNU_ Makefile magic (instead of
autoconf) to address that. But I always realized that this was a
quick-and-dirty way to get things built because we wouldn't want the
source package for 'make' to assume that the user already has GNU make
installed -- users might sometimes have some other (lesser ;-) 'make'
installed that they need to build GNU 'make' with. Reading the messages
in mingw-user, I see that John Cronin is well along on fixing the
configure script (via autotools input) to build the w32 stuff
conditionally. Which is great. 

   Thanks much,
     Soren A
------------------------------------------------------------------------