make-w32
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: MS compiler 7.1 (Visual Studio .NET 7.1 and DDK 2003) issues withmak


From: Jerker Bäck
Subject: RE: MS compiler 7.1 (Visual Studio .NET 7.1 and DDK 2003) issues withmake 3.80
Date: Tue, 26 Apr 2005 15:59:34 +0200

Hello Alessandro

Calling conventions
Alessandro Vesely:
> Yes, they are used. Yet AFAIK, they don't _have_ to be used. 
> Why would users have to deal with them?
...
> It looks as if MSVC and Borland can compile perfectly well 
> using the default C calling conventions. If I understand your 
> point correctly, the only reason they would be needed is in 
> case some user mindlessly adds, say, `/Gr' to the command 
> line when compiling GNU make. Perhaps a couple of lines in 
> README.W32 to prevent such experiments may make sense: that 
> accounts for less effort, in coding, testing, and 
> maintaining, than the solution you propose.

First, my primary task was to find compatibility issues with the Microsoft
compiler. I used the /W4 and /Gz switch to get maximum diagnostics. You
surely agrees there is no doubt that Win32 versions of GNU make are buggy.
Is that a fact of acceptance? Could and should we do something about it? If
you look in the code you can see that many efforts been made to support the
Windows platform, and in the mailing archive, I have seen that you have been
part of this work. I assume that acceptance or rejections of changing the
official code is made by the big boys at the top somewhere. Am I the one to
be conservative? Is it not a good thing that features of our tools being
handled by the code.

Even if the users don't have to use them, they might do it anyway as you
pointed out. I mean: With a small effort the GNU make code will be robust
enough to catch these suckers doing what they are not supposed to.

Besides, the tool I am using and made some pushing for here, use the
__stdcall calling convention as default. You can of course change that but
if you ever looked at the DDK build environment you would understand my
point.

On release builds, the Borland community have made performance tests of
using different calling conventions. They recommend __cdecl as default. 

And finally:
I dare to say this: I have growing thought of compile GNU make as library,
skip the main.c and export the needed functions. You can then use make as
part of an IDE or in a Windows GUI complemented with say autoconfig? In that
case: You really need to handle not only calling conventions, but even the
__declspec(export)/__declspec(import) on ALL exported functions. See the PNG
project.

Such ideas and efforts will soon go out of hand if they do not get support
in the original code. The might even be considered hostile by the official
maintainers. An open minded approach to compatiblity is then an easy way to
prevent such events.

Kind regards Jerker






reply via email to

[Prev in Thread] Current Thread [Next in Thread]