[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 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