Re: WIN32 compilation, the spirit of GNU software.

[Cyrille Chepelov <cyrille chepelov org>]

Le Thu, Aug 22, 2002, à 04:40:54PM -0400, Tim Ellis a écrit:

> Personally, I don't mind requiring *ix emulation and an X server. Cygwin
> gives us both those things pretty transparently... Am I missing something?
> Is there some Win32 platform on which Cygwin/X doesn't work?

Have you even _tried_ the native Win32 port of dia ?
 
> In what fashion would Dia be restricted? I've run it from a Linux box
> displaying on X running under Cygwin and it appears identical to when it
> displays on X running under Linux... Why would the fact that the Dia
> executable itself is compiled under Win32 change this?

        - it would be slower than the current native build, especially when
it comes to display (have you just _tried_ compare the speed of dia on a
remote native X display and the speed of dia on a remote cygwin/X display ?
I have. dia-linux on a Linux remote X on a 10BaseT beats the crap out of
dia-linux on a Win32 remote X/Cygwin on a 100BaseT network.).
        - it would take ten times the download (dia proprer PLUS Cygwin)
        - it would be unable to print except using Ghostscript (instead of
just using the existing and working print facilities.
        - etc.

There is nothing wrong with autotools + configure on Win32. It can certainly
be done, using some of cygwin and/or some of mingw32. I would find this a
desirable goal. Saying that an X/Cygwin port of dia would be better than the
existing native Win32 port is, IMO, ridiculous.

Now, when JMD came at the beginning of this week, claiming that dia on Win32
FTBFS and therefore violates the GPL, it was not because dia didn't build on
cygwin (which it still does not), but allegedly doesn't build with the very
same tools Hans uses to build. The only problem that despite being told to
do so, JMD repeatedly refused to install the sources for the dependent
libraries. I would simply say that JMD lacks the technical and social skills
to read a damn readme and understand that a depended upon library stands on
itself and needs to be rebuilt by itself before the main application can be.
 
To summarise:
        - I believe dia on Win32 (regardless of native or cygwin/X) is a
desirable thing
        - We had such a thing, with the fastest arrangement (native Win32)
until the beginning of this week.
        - The native port work(s|ed). A Cygwin/X port is vapourware, and
very likely to be less performant than the native port.
        - The build system for the native build uses Microsoft NMAKE
        - There have been attempts at using mingw32 as a better native
build system, a build system which would use autoconf/automake/GNU make/gcc
        - This particular work is not finished.
        - I believe it would be a very good thing if that particular work
was finished.
        - Regardless of the build system used, one must use dependent
libraries compiled with the same compiler (be it MSVC, BCC or GCC)
        - There has been no deliberate attempt to prevent anyone from
building from source on Win32. It just has not been done much outside of
Hans' laptop. But it _can_ be done, and there is no deliberate attempt to
retain anything (despite what JMD pretends to believe).
        - *I* can't and don't build on Win32, because my employer's
computers don't exist for my personal gain, but for my employer's.
        - anyone behaving in a cooperative, friendly and constructive way is
welcome to compile, modify and contribute to dia on any platform.
        - in fact, anyone complying with the GPL, no matter quirky the
behaviour, is allowed to do so.

> Where does wine fit in here? Why would I need wine to either compile or
> run Dia in Win32??? Why would I ever even attempt to compile or run wine
> in a Win32 environment at all? I would hope I could just run Win32 code
> natively in a Win32 environment.

I believe Wine was quoted by JMD.
        
        -- Cyrille 

-- 
Grumpf.