Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
From: "Paul Garceau" <pgarceau AT qwest DOT net>
Organization: New Dawn Productions
To: cygwin-apps AT cygwin DOT com
Date: Tue, 20 Mar 2001 16:27:01 -0800
Subject: Cygwin --> Mingw
Reply-to: Paul Garceau <pgarceau AT qwest DOT net>
Message-ID: <3AB784D5.16534.AD1D0B@localhost>

Hi folks,
	
	Just recently subscribed, and going through the archives to find out 
where everyone is at re: Cygwin and Mingw.

	My own opinion is that there is no real need for a Mingw cross-
compiler, even though it has been suggested as the best method to use 
for developing mingw apps within the Cygwin development environment.  I 
did mention this some time back, but guess it didn't make it here.

	I guess I need to say here that I think of the development environment 
in a rather non-traditional way...to me, it is the environment that 
supports various sorts of ports, builds and how those components are 
put together.

	Because of this (possibly naive approach), it seems to me that if we 
simply extend the functionality of certain gcc switches such as -mno-
cygwin, -mwin32, etc. we can accommodate developing Mingw apps within 
the cygwin development environment.

Some other definitions (open to correction):

	"Cygwin", to me, means the collection of development tools which are 
useable via tcsh which allow developers to build, port or modify Unix-
like tools for use on a Win32 platform.  "Mingw", to me, is the same as 
saying, "Cygwin without reliance of cygwin1.dll" as that was the Spirit 
of Mingw when Colin was using the cygwin development environment to 
build mingw runtimes, etc.  (yes, I know, I am showing my age...but 
personally that is ok.

End of definitions.

	I started using Cygwin as my win32 c/c++ build environment, and later 
discovered Mingw, which as I recall, was basically Cygwin w/o the 
cygwin dll being included in the libs, etc.  It was about that time 
that I shifted my main focus to Mingw.  I have also been keeping up 
with Cygwin as much as I can in those areas where mingw and cygwin 
overlap.

	Now, hopefully this will allow those folks here who don't know me to 
have a better sense of where I am in regards to mingw and cygwin...

To the issue at hand --

Kees Zeelenberg wrote:
> 
> On the other hand, it _is_ common for MS-Windows packages to have the 
installation directories
> separated by package, and not by file type. E.g package X is 
installed in "\Program Files\X",
> and not the Unix way with its binaries in \Bin, its man files in 
\Man, and so on. There may be
> advantages to the Unix way, but there are also advantages to the 
Windows way: it is much easier
> to remove a package, old files that are no longer needed can easily 
be removed, and it is much
> easier to see which file belong together. Moreover, the use of large 
disk drives has led to the
> use of multiple drive letters, and so you cannot rely on it that 
\Bin, \Etc, \Man, \Share are
> on the same drive. And who would want to use up his environment space 
by setting loads of
> environment variables? Of course a group of Windows developers such 
as Mingw could decide to do
> it the Unix way, but I don't think it would be a wise decision, if 
only because the group is
> relatively small.
> 


Earnie wrote:

Since Chuck is asking about Cygwin and where to put MinGW built
libraries, I'm including the cygwin-apps list on this discussion.  They
may be MinGW built but it's Cygwin that is the main topic of 
discussion.

If any library that is downloaded from the Cygwin official site also 
has
MinGW libraries then those libraries should go into /usr/lib/mingw/. 
Libraries not on the official site that also include MinGW libraries
should go into the /usr/local/lib/mingw/ directory.  GCC-2.95.2-9 has
been renovated to fit this model.

Now, if the library package also contains binaries, such as the gettext
library package; IMO, the MinGW binaries should *not* be distributed in
the Cygwin package unless you distribute a different package for the
MinGW specific libraries.

  If that is the case, the current MinGW
standard is to --prefix=/mingw when configuring the package.  I package
the tarball at the bottom most level so that it contains only the base
level directories.  However, IMO MinGW specific packages should not be
distributed from the Cygwin net distribution.

Earnie.

Paul G. writes:

(admittedly this may be considered a "me too", but in fact it is my 
preference on those things related to mingw).

Earnie writes:

	"...MinGW specific packages should not be
distributed from the Cygwin net distribution."

	I would agree with Earnie on this aspect, but probably for different 
reasons.

	To me, it makes no sense to waste space in the cygwin distribution 
package (and the related maintenance tasks) to include Mingw specific 
packages.  Especially considering the fact that Mingw compiled/linked 
apps (C++) will run, w/o problems, under the Cygwin tcsh.

	The only exceptions I can think of have to do with the basic Mingw 
development tools (runtime, win32api).  Historically speaking, Mingw 
binutils run just fine under Cygwin tcsh and can be easily obtained 
from the Mingw site.

	It is far simpler, and far less hassle for the Cygwin development 
group, to have those folks using Cygwin development environment and who 
need the mingw specific things to simply obtain them via download from 
other places on the net.

	Peace,

		Paul G.


Nothing real can be threatened.
    Nothing unreal exists.