[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mingw-users
Subject:    Re: [Mingw-users] Archives and 'X'
From:       Greg Chicares <gchicares () sbcglobal ! net>
Date:       2009-01-30 13:45:38
Message-ID: 49830482.4000302 () sbcglobal ! net
[Download RAW message or body]

On 2009-01-30 10:30Z, John Emmas wrote:
>
> How reliable is the "configure" and "make" build model under MinGW?  I'm 
> only asking because this is an area that I've found very hit-and-miss in 
> Cygwin.  Both the configuration files and makefiles often need to be 
> "cygwin-ised" (i.e. patched) before they can be built and this is usually 
> done by a "cygport" utility.  The downside is that unless you're quite 
> expert with Cygwin, the quickest option to getting something built is 
> usually to wait until one of the experts builds it.  Sometimes "configure" 
> and "make" just work "right out of the box" but equally as often, they 
> don't.  Is that also the case for MinGW?

It's fruitful to view this in terms of "programming by contract":
  http://en.wikipedia.org/wiki/Programming_by_contract
where you desire a successful build as a postcondition resulting
from combining different components, which may have their own
preconditions and postconditions. To that end, I'll speak very
generally and gloss over many details.

Cygwin provides a posix emulator. Its contract is to fulfill your
postcondition for posix code that doesn't exceed its emulator's
capabilities, and for cross-platform code that needs no emulator.

MSYS is a minimalist fork of Cygwin. Its contract is to fulfill
the postcondition for cross-platform code that needs no emulator.

[And MinGW is simply a gcc toolchain--the one MSYS typically uses.
Cygwin provides its own gcc toolchain that's nearly identical.]

In this context, the contract for an application you want to build
is just to be portable: its postcondition must satisfy the build
platform's preconditions. Many applications don't do this; that's
probably the main reason why some "just work", while others don't.

If the application calls the posix fork() function, then it's not
portable to a non-posix platform like MSYS + MinGW, though it'll
probably work with Cygwin. Similarly, if it calls windows system
functions, it's not portable to a posix platform. That doesn't
mean it's bad code; it's just not portable across platforms.

There's no way that MSYS + MinGW can build a posix-dependent
application, and that's not a defect of MSYS. If you need that to
work, you must change the application to make it portable (or wait
until someone else does). It's not useful to think of modifying
MSYS to fill this gap, because MSYS is already fulfilling its
contract.

Because Cygwin's contract is broader (remember, MSYS is a subset
of a fork of an older version of Cygwin), it's unlikely that an
application will build on MSYS if it doesn't build on Cygwin.

Cygwin does strive to conform to the published posix standard.
Patching a posix application so that it works on Cygwin might
entail working around a Cygwin issue, but it may just as well
mean changing application code that relied on some behavior not
required by the posix standard.

Applications may also need to be patched because they rely on
unspecified programming-language behavior. An uninitialized C
variable might reliably have the value zero on *nix, for example,
but have a random value on msw, and both those behaviors conform
to the C standard. Hence, this syllogism:
  My program works great on GNU/Linux.
  It compiles and links fine with MinGW, but fails at run time.
  Therefore MinGW is broken.
is generally not accepted at face value on this list, because the
problem is usually that the program is defective. Fixing it isn't
a matter of "adapting" it to MinGW, MSYS, Cygwin, or msw: instead,
it means improving the program so that it works reliably on many
platforms, rather than by accident on only one.

Here's another example that frequently comes up on this list. The
order in which libraries are specified to the linker doesn't seem
to matter on ELF platforms as long as shared objects are used,
but it matters for static linking on ELF, and for PE always. It's
possible to write linker commands that work reliably for both,
but sometimes a developer omits to do that, so the makefiles must
be changed to make them more portable.

Thus, my answer to your question:
> How reliable is the "configure" and "make" build model under MinGW?
is that it's quite reliable; and that it often doesn't do what you
want; and that there's no contradiction between those statements.
There's an awful lot of non-portable code out there that isn't
meeting the "contract" described above.

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
MinGW-users mailing list
MinGW-users@lists.sourceforge.net

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users

_______________________________________________
This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.

Most annoying abuses are:
1) Top posting
2) HTML/MIME encoded mail
3) Improper quoting
4) Improper trimming
[prev in list] [next in list] [prev in thread] [next in thread]