Hi Gün,

2011/1/13 Guenter wrote:

> commit  61623b74e3337c9be44a7865eeb558f64c00576f
> I dont believe that the check for BCC-make makes much sense since I know
> only 2 other make tools which may understand the syntax up to the point that
> the error message is really printed out, that is Watcom wmake and M$ nmake,
> and since both are differently named its unlikely that someone uses these
> when he wants to compile with BCC; I guess you want to separate from GNU
> make which is named same, but unfortunately this doesnt work (line number
> wrong since output below is from testmake):
> Makefile:2: *** missing separator.  Stop.
> therefore I think we can remove this check again.

My intention with the check was to force a failure ASAP if a
non-BCC-make was used, to prevent failure further on when specific
BCC-make features are used. Ancient versions of MS QuickC also used a
make executable named 'make.exe', as well as a lot of other make
versions, not only the GNU one. I believe that the macro used for the
check __MAKE__ is specific for borland-codegear-inprise-embarcadero
make and that unfortunately there is no other one that can be checked
that identify that make family. It is true that when the condition is
not met, the !error directive might not get properly interpreted by a
non-BCC-make failing right away at that point, even if the error
message is not shown it points directly to a line in which a user can
read the reason behind the failure.

If a non-BCC-make defines __MAKE__ macro, then the check makes no
sense. All that said, I really don't care if the check is kept in
place or removed. If you think we are better without it, just go ahead
and remove it.

> commit  5f7d34811a1ff21d4a8962e3c7c99d4a702bd684
> I think we should use here '!ifndef BCCDIR' so that all envvar tests look
> the same; the helpfile states that this syntax is equal to '!if
> !$d(BCCDIR)', and a test for a defined but empty BCCDIR var seems a bit
> strange since AFAIK its hard to even produce an empty env var in Win32
> world.

Theoretically it would be possible to do something dumb like "make
Makefile.b32 -DBCCDIR". But given that it doesn't work with BCC-make
5.20, I suppose that it is also broken on previous versions. Change
done in the repo.

Before answering your next paragraphs, I would like to make clear that
I discovered your changes when I was pushing mines, and had to merge
all the stuff together, which might have resulted in something which
is not fully the-proper-thing. So let's take a closer look...

> commit  42f5e8a0f1729b17547acfc6625e58e583811e8d
> its unclear to me why you changed the CP / RM macros and did then append the
> NUL redirection to the commandline - what was wrong with my macro define? It
> works fine for me on XP and W2K3, and avoids to append the redirection to
> each single commandline + makes it possible to just change the macro only in
> case you need (for debugging purpose or whatever).

CP macro no longer used in Makefile.b32, so I got rid of it.

old> RM = del
gün> RM = del /q /f 2>NUL

I dislike doing stderr redirection before the very end of a command,
but I recognize it is a matter of personal preference. OTOH I could
ask why do you use /q and /f, they are not needed in current
Makefile.b32

Change done in repo... Get rid of stdout redirection to NUL and change
RM and RMDIR definitions to...

new> RM = del 2>NUL
new> RMDIR = rmdir /s /q 2>NUL

> Then why did you change all paths to use backslash instead of forwardslash?
> I admit that I had probs when I tried to use ilink32, but at least the
> makefile version before your commit worked fine with forwardslash.

Backslash is the proper path separator for systems capable of running
BCC compiler, DOS Windows and OS/2, so the question would really be...
Why should we use the forwardslash instead of the native path
separator on those systems?

> The macros for mkdir and rmdir let BCC-make execute my GNU binary pedants
> instead of the internal CMD commands, I think we should use the md / rd
> abbreviations here.

Do you refer here to the macro name or to the command name itself? No
objection either way. Please, change it yourself.

> Please take this as comment and not as rant :-)

:-)

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html