RE: Detecting the need for -mwin32 in newer cygwin gcc's

["Paul Garceau" <pgarceau at qwest dot net>]

On 9 Mar 2001, at 10:14, the Illustrious Robert Collins wrote:

> > -----Original Message-----
> > From: Paul Garceau [mailto:pgarceau@qwest.net]
> > Sent: Friday, March 09, 2001 9:38 AM
> > To: cygwin@cygwin.com
> > Subject: Re: Detecting the need for -mwin32 in newer cygwin gcc's
> > 
> > 
> > Ok, so here are my own ideas...
> > 
> > On 7 Mar 2001, at 23:49, the Illustrious Alexandre Oliva wrote:
> > 
> > > On Mar  7, 2001, Christopher Faylor <cgf@redhat.com> wrote:
> > > 
> > > > Basically, I think we need something like a 
> > AC_PROG_GCC_USES_MWIN32.
> > > 
> > > I have mixed feelings about having this macro in autoconf.  On one
> > > hand, it would be kind of promoting the use of proprietary 
> > software. On
> > > the other, I see it would be a convenience for projects 
> > that really need
> > > it, even though it could probably live with CFLAGS='-mwin32 -g -O2'.
> > 
> > 	My own feeling are that autoconfig should _not_ be made 
> > more complex 
> > than it already is (this coming from someone who hasn't been able to
> > get a working autoconf ported, but has instead modified the switches
> > on gcc/g++ to accomplish the same things that autoconf make
> > convenient. [pun not intended]).
> 
> What problems have you had geting autoconf working? I've had no
> _autoconf_ difficulties with a long list of packages (squid, wget,
> readline, glib, ...)

	Thanks for asking...to avoid going OT, suffice it to say I do _not_ 
use the cygwin bash shell unless I have absolutely no choice 
whatsoever...a very rare occasion.
	If you are porting for a single platform, say Unix, then it is 
expected that autoconf will work and is present.
	However, I do not port Unix to Unix, but Unix to Win32, Linux to 
Win32, Win32 to Solaris, etc.  Autoconf is fine when the shell support 
exists, but for me such support does not exist, nor do I expect it to.

> 
> > 	It would be easy enough to use the -mwin32 switch, or 
> > set the specs so 
> > that it is assumed that the build is for a win32 machine unless 
> > otherwise noted (-mno_win32).  Or, depending on the priorities trying
> > to be promoted and supported for Cygwin, the default can be
> > -mno-win32, thereby forcing the developer to use -mwin32 if they want
> > to build a win32 app. 	In the latter case, if -mno-cygwin is being
> > used then the default is defined as -mwin32.
> 
> While it's 'easy enough' for someone who's been on this list and
> watching the changes happen, it's not intuitive, or even logical, to an
> old unix hand, who just downloaded cygwin via setup, downloaded (say) an
> emacs tarball, and then runs ./configure; make; and hits lots of errors
> (because they needed -mwin32 and _didn't know that_.

	I don't think I am arguing with you.

> 
>  The goal is to make the porter's (who is not necessarily the developer)
> job easier.

	Well, I could argue about this, but won't.  I do port a lot of 
software (both deep and shallow) when I have the time to do so.  I am 
also a developer.

> 
> The porters goal is to allow the user to run
> ./configure
> make 
> make install
> 
> and have the program compile and install efficiently.

	I agree, that is the ideal...I seriously doubt that this can be 
accomplished without having a bash shell or something similar that can 
support autoconf...notwithstanding platform limitations.  Most often it 
takes some work to get a Unix C/C++ app to function properly on a Win32 
platform.  Cygwin minimizes this work at a cost.

> 
> So the gcc specs are interesting, but moot: some packages need one
> default, some the other. So the porter wants the configure script to
> find the correct gcc switchs, _for this install_ of cygwin. I.e. with
> gcc 2.95.6-5 or -8, where the default is opposite!. And we want the
> porter to have an easy time of this :]

	So, the porter can change an environment variable setting or simply 
add the necessary gcc/g++ switches when the need arises to do so.

	An example that springs to mind...

	if you are using the setup.exe program, at one point you are given a 
choice as to how you want your cygwin environment setup.  It would be a 
simple matter to add the switch to the setup.exe (a "tick" in a box 
that says "Compiles for Win32", which would be equivalent to saying
gcc <*.c> -o<*.exe> -mwin32).

	The simplest thing to do is to take your existing Unix makefile(s) 
(autoconf generated or not) and simply change the gcc/g++ switch (CC, 
CPP) to accomodate Win32 builds.

	I think the real question has to do with convenience for Unix porters, 
not with practicality.  Thus my earlier question (see earlier email) 
re: whether the developer/porter wants to build for Unix or Win32.

	Peace,

		Paul G.

> 
> Rob
> 
> > 	Peace,
> > 
> > 		Paul G.
> > 
> > 
> > Nothing real can be threatened.
> >     Nothing unreal exists.
> > 
> > --
> > Want to unsubscribe from this list?
> > Check out: http://cygwin.com/ml/#unsubscribe-simple
> > 
> > 
> 
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
> 
> 




Nothing real can be threatened.
    Nothing unreal exists.

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple