This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Cygwin --> Mingw
- To: cygwin-apps at cygwin dot com
- Subject: Cygwin --> Mingw
- From: "Paul Garceau" <pgarceau at qwest dot net>
- Date: Tue, 20 Mar 2001 16:27:01 -0800
- Organization: New Dawn Productions
- Reply-to: Paul Garceau <pgarceau at qwest dot net>
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.