make-w32
[Top][All Lists]
Advanced

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

Re: [Mingw-users] Re: make'ing make-3.18beta4 under mingw/msys - "undefi


From: Keith MARSHALL
Subject: Re: [Mingw-users] Re: make'ing make-3.18beta4 under mingw/msys - "undefined reference to `sleep'"
Date: Wed, 4 Jan 2006 10:50:52 +0000

Eli Zaretskii wrote, quoting me:
>> Maybe, but under MSYS, MinGW builds are supposed to be accomplished
>> by using a conventional
>> 
>>       ./configure && make
>
> I don't know about ``supposed to''; AFAIK, GNU Make didn't support
> MinGW builds out of the box until such a support was added in
> 3.81beta3.  ...

Yes, `supposed to'.  This is the very essence of the raison d'ĂȘtre for
MSYS -- to provide a minimal GNU/POSIX-like environment, which when it is
coupled with the MinGW port of GCC, permits the building and installation
of GNU Coding Standards conformant applications using the conventional
`./configure && make && make install' mantra.

> Besides, I think a tool so basic as Make, which is a prerequisite to
> building other tools, should have a simple build procedure that
> doesn't require a working Make, a port of Bash, and other utilities
> that are hard to find on Windows.  Even Unix has build.sh.

MSYS provides those so called hard to find tools, in one handy self
extracting package:
http://prdownloads.sourceforge.net/mingw/MSYS-1.0.10.exe?download

Add MinGW to that (either the last stable release):
http://prdownloads.sourceforge.net/mingw/MinGW-3.1.0-1.exe?download

(or the latest proposed development release):
http://prdownloads.sourceforge.net/mingw/MinGW-5.0.0.exe?download

and you should have everything required for GNU Coding Standards
conformance, in a build environment.

However, I understand your point about the `chicken-and-egg' dilemma,
on the horns of which make may be found; perhaps build.sh should also
work with MSYS, but I don't have the time to explore this possibility
at present.

>>> If I build the MinGW port with build_w32.bat, I don't have any
>>> problems.
>>
>> You will, if you try to run *.bat files under MSYS; they simply do
>> not live there, in any natural sense
>
> Which is IMNSHO a bug in MSYS.  (Compare that with the DJGPP port
> of Bash, where batch files would run with no problems at all.)

Well, to express a `not so humble opinion' from such a clear position
of ill informed ignorance is, IMHO, simply a statement of arrogant
stupidity.  This is NOT a bug in MSYS.  Does bash on GNU/Linux, or on
any other POSIX platform process Windows/MS-DOS format *.bat scripts?
No?  Then why on earth would you expect it to do so on MSYS?  The
ability to do so is clearly beyond the scope of its stated design
objectives, contrary to the case with DJGPP.

>> (however,
>> 
>>       start cmd.exe //c build_w32 ...
>> 
>> might work).
>
> What's wrong with a simpler "cmd.exe /c build_w32"?

Yes, even `cmd //c build_w32 ...' might also work; the `start' variant
is used to run the cmd.exe task as a background process.

> And what's with the doubling of the slash in "//c"?

Clearly stated in MSYS documentation, if you took the trouble to
research the facts, before leaping into print to show off your
ignorance; the doubled `/' is required to prevent MSYS from
translating `/c' to `c:/', before handing it off as an argument
to cmd.exe.

Regards,
Keith.




reply via email to

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