Re: [Mingw-users] Re: Potato Chips

[Zed A. S. <ze...@ze...>]

Oscar,

I do know how to use Makefiles (and autoconf, and automake, and imake, and
Ant, and bsd make, and dmake, and many, many more), but I choose to use
Scons because it is more powerful than the mess that is
Makefile/automake/autconf.  Things were MUCH worse with automake, as I
couldn't even get automake to properly configure the app.  It kept grabbing
stuff from all kinds of places.  M4 macros came from Cygwin, but the
autoconf .sh scripts came from MinGW.  It was a nightmare.  With Scons, I'm
able to compile on just about everything (except Win32) with no
modifications.

Considering my application (http://bombyx.sourceforge.net) now runs on four
platforms (Linux, FreeBSD, MacOSX, and Win32), I think I know a bit of
something about software configuration management and porting.  But, while
your non-trivial application may work, mine doesn't.  This is probably for
several reasons which are all my fault (because, true to open source form,
mingw is ALWAYS right, and I'm always wrong, since no one has ever heard of
user centered design).  I simply don't have the time to mess with it when
there is a perfectly good alternative.

I'm sure, in a few years, MinGW will be good enough for me to work with
seamlessly.  Until then, I'll just play with it and track the project. I
still think something like fink would help this.

Finally, if MinGW is not supposed to work with Cygwin or MSYS, then how do
YOU use Makefiles?  You need a shell to run them right?  You need a bourne
compatible shell to do autoconf and friends right?  And you don't use MSYS
or Cygwin?  I'd really like to know what people use for their build
environment, because there is obviously some magic that I'm missing to get
this all working.

Anyway, I'll stop beating this dead horse.  I'm not bashing the project, I
just gave up on it for now.


Zed

On 6/3/02 6:17 PM, "Oscar Fuentes" <of...@wa...> wrote:

> "Zed A. Shaw" <ze...@ze...> writes:
> 
>> On 6/3/02 5:11 PM, "Oscar Fuentes" <of...@wa...> wrote:
>> 
>> Oscar,
>> 
>> Because, if I use Cygwin, and try to install say, FLTK
>> (http://www.fltk.org), it will put them in /usr/local of CYGWIN, but when I
>> run MinGW (from Cygwin) and tell it -lfltk, it tries to load the library
>> from MinGW's /usr/local.
>> 
>> So, if I have my libraris in, C:\cyginw\usr\local, and MinGW is in C:\mingw,
>> then MinGW tries to load them from C:\mingw\usr\local, and not
>> C:\cygwin\usr\local.  Even then it is still not clear where MinGW expects
>> things to be, and setting stuff like LIBPATH is just not honored by MinGW.
>> 
>> So, what I'm forced to do is load MSYS to do any linking, and muck with
>> paths where software is installed in order to get MinGW to properly load the
>> right headers and libraries during compile.  Then, if I'm lucky, I won't run
>> into problems with ranlib not finding things and such.
>> 
>> Either way, it's a nightmare.  I've found that I can do about 90% of
>> everything in MSYS, but I use the Scons build system (http://www.scons.org)
>> which needs python.  Since MSYS hasn't got python working (trust me, I
>> tried), and since I can't seamlessly call Cygwin binaries from MSYS, I'm
>> basically stuck working in this weird half-assed MSYS/Cygwin world that
>> barely works.
>> 
>> In VC++, I make project, I add files, I setup libraries and headers, I click
>> build, I get binary.  Easy.
>> 
>> So, that's why I think something like fink (http://fink.sourceforge.net) for
>> MSYS would be great.  Then, it would be easier to port and distribute
>> software.
>> 
>> Anyway, that's what I think.
> 
> From your description, my conclussions are this:
> 
> 1. Learn that MinGW is not a Cygwin part. It is not required that
>  MinGW works well with Cygwin. Much less MSYS. Earnie explicitly
>  arranged things for Cygwin executables not working with MSYS.
> 
> 2. Learn how to use Makefiles. They are *much* more powerful and
>  efficient than whatever IDE is around.
> 
> In any case, you are free from moving libraries to whatever directory
> you want. Although LIBPATH should be an easy to fix issue, the -L
> option works fine with MinGW, that is, if you specify the paths in the
> correct way (remember: MinGW's gcc is a Windows native system).
> 
> I'm using MinGW for almost a year now and my far-from-being-trivial
> main project builds correctly either with MSYS, Cygwin or NT
> shells. The libraries and header files are scattered on several disk
> drives.

-- 
Zed A. Shaw