[Top][All Lists]
[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 with ma
From: |
Paul D. Smith |
Subject: |
Re: MS compiler 7.1 (Visual Studio .NET 7.1 and DDK 2003) issues with make 3.80 |
Date: |
Fri, 22 Apr 2005 17:21:25 -0400 |
%% Jerker Bäck <address@hidden> writes:
jb> The GNU make is a must have but there are a lot of different Win32
jb> versions around. Some of them seems not to be working properly
jb> (ie. minGW, Cygwin 3.80 (in Mozilla FireFox)). This is not good
jb> since it will render GNU make a bad reputation. So I decided to
jb> try to compile my own, which I did and it's working great! The
jb> tool I used was the Windows 2003 DDK - it's free, comes with
jb> complete runtime and a full optimizing compiler. Binaries will
jb> also link to the official runtime included in Windows.
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.
jb> However, before I was able to compile there were some work needed
jb> to be done.
Before you attempt to start larger modifications like this you should be
sure to get the latest version of the code. The very latest version is
available from CVS. There is a beta of the next release which has
"pretty recent" versions of the code:
http://make.paulandlesley.org/make-3.81beta2.tar.gz
jb> Example:
jb> #if defined __STDC__ && __STDC__
jb> ...correct expression
jb> #else
jb> ...bad expression
jb> #endif
jb> I assume the purpose of this is to determine the runtime library
jb> used.
Well, in some cases maybe. Mostly it's used to determine whether we're
using an ISO-compliant version of the C compiler, or one from the
pre-ISO days (that might not support things like const, void, etc.)
jb> The Microsoft compiler normally sets __STDC__ to false to indicate
jb> it is using Microsoft extensions to ANSI C.
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.
jb> Note: Sometimes the constant "WINDOWS32" is used in the code in
jb> same context. That is by my opinion not good because it could be
jb> confused with "WIN32" meaning "compile for windows" regardless of
jb> which runtime used. The expression #ifdef HAVE_UNISTD_H seems also
jb> sometimes being used to determine runtime library.
HAVE_UNISTD_H is used to determine whether the unistd.h header file is
available, and that's all. If you see someplace it's used differently
please let me know.
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.
Instead, the configuration checks for specific FEATURES that are needed,
and if those are found the macro is set.
--
-------------------------------------------------------------------------------
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