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: Sat, 23 Apr 2005 04:01:09 +0200

Hello Paul and thanks for the quick reply!

Paul Smith <psmith at nortel.com> writes:
> There is a beta of the next release which has "pretty recent" 
> versions of the code:

Thanks I will try that!
Note, all I did with my build was to ensure the right headers was included
and disable any redefined prototype. See this:
extern void* malloc(size_t); is not the same as
_CRTIMP void* __cdecl malloc(size_t);

I did NOT change any code!

> I'm happy to work with anyone on the Windows port.  Note that 
> the Windows versions of GNU make is maintained by volunteers, 
> since the developers don't have any access to Windows 
> platforms.  This makes changes there somewhat tricky, as 
> there has to be some kind of consensus behind them.  The 
> exact process is, unfortunately, ill-defined.

I understand. The lack of a common platform is the real problem. In Windows,
the de facto standard is the Microsoft compiler. It may seem as a good joke
to build make.exe with build.exe(!), nevertheless I propose the Windows DDK
since it's the offical tool used by Microsoft to build the Windows OS and
all Microsoft SDK's. It's free and includes a complete build system. The
build environment is very easy: Just specify the name and type of the binary
and list the source files in a text file. For the development team of GNU
make it would be very easy to maintain. If a release will pass this tool,
all other compilers for Windows will surely have no problem.

GNU make is a nice tool and widely used in crossplatform projects (ie
Mozilla FireFox). A reliable Windows release supported by the developers is
in great need. 

> Please be clear on how the configure macros are used in GNU 
> make (and any autoconf-ed package): they do NOT get set, 
> generally, on a per-operating system or even per-runtime 
> library basis.  For some systems like Windows, some 
> exceptions are made since the configuration step does not 
> properly work there.

Exactly! How about that? I can just imagine how much time the Mozilla
developers spends on getting the makefiles work on both Linux and Windows.

Microsoft extensions
> That's incredibly stupid.  The ISO standard defines that 
> __STDC__ should be set if the compiler is standards 
> conforming.  All a compiler has to do to be standards 
> conforming is to accept all standards-conforming programs and 
> compile them correctly (according to the standard).
> There is absolutely no problem with the compiler accepting 
> _EXTENSIONS_ to the language and still defining __STDC__, as 
> long as they don't break a standards-conforming program.

...yes, well I suppose it have historical reasons, anyway that is how it
works.

Kind regards Jerker







reply via email to

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