Re: new win32 port of GTK http://introspector.sourceforge.net/dia_w in32.htm

[James Michael DuPont <mdupont777 yahoo com>]

--- Tor Lillqvist <tml iki fi> wrote:
> > The current port is difficult to use.
> You mean difficult to build? I agree.

Difficult to rebuild from scratch. 
It was difficult to find all the dlls and libs when i tried.
And the worst, it was difficult to get a set of all the sources I
needed to do the porting.

> > It is based on the idea of downloading dlls from all over the net.
> Hmm, to *build*, or to *use* the prebuilt DLLs I provide? 

The point is that the dlls get separated from the sources and then the
thread is sometimes broken. There is a for example a typical user 

http://www.videolan.org/vlc/doc/win32/Cross-Compile-Howto.txt
they just zipped up all the headers and binaries they got from you,
and redistributed them. If asked for the sources, you get a blank.

The same with the dia installer. 

That is nice, easy to use, but it is not GPL compliant. 

If you Tor make the effort to put a snapshot of all the needed sources
in the same place as the binaries, and tell people who want to
re-distribute them that they need to to take that snapshot, or give
them a written offer to send them the sources, then you are GPL
compliant. 

> To build
> it, DLLs of dependent libraries aren't enough, you will need headers
> and (import) libraries.
> But the same is true when building GTK+ for Unix, too. Only on a
> Linux  box with typical developer packages installed can one be 
> reasonable certain that developer packages for libpng, zlib, iconv, 
> etc are present.
> 
> Even on something as common as Solaris 7 building a fully-working
> (including i18n) GLib and GTK+ can be hard. One can imagine that more
> exotic Unices have even more quirks.
> 
> > There is no place that you can get all the requirements for
> building
> > GTk and *all* prerequisites.
> 
> > Many people who distribute the dlls dont put the source in the same
> > place as required by the GPL section 3.
> 
> Please be specific what DLLs and what sources you are talking about
> here. Do you mean that when distributing binaries of GTK+, one needs
> to distribute the sources for, say, libtiff, from the same site?

See my mail, if you link in the libtiff to the gdk, and need it to run,
and redistribute the binaries, then yes. If you dont distribute the
binaries, then dont worry. But the people who do want to distribute
them should be made aware of the issue.

Specifically, if you provide libs, dlls, and link libaries, then you
should provide the sources to create them, in the same place. This is
clearly stipulated by the GPL.

> > This problem is compounded by the fact that all the individual dlls
> > are build by different people, and none of them are located in one
> > spot.
> 
> So, your solution is to add another set of perhaps incompatible
> library builds (DLLs or static) built by one more person (you)?

my solution is to set up a debian package repository of all the sources
and binaries in one spot. All that work togeather and are easy to
build.

> In fact, I think it's a *good* thing that if somebody else already
> provides a build of some library, you use that instead of
> unnecessarily rolling your own essentially identical build (unless
> you intend to provide some new feature in said library, like I do in
> my gettext build).

If you dont provide the binaries, then you dont need the sources.
If you say, you need binaries from them to use this, then fine. But if
you provide a snapshot of the libs, you need to provide a snapshot of
the sources.

> (Last year one person (rightly) complained about me distributing my
> own builds of libiconv, libpng etc, when there were perfectly useable
> Win32 builds available elsewhere. I agreed and stopped using and
> distributing own builds of these and instead added links to those
> "canonical" builds.)

Again, libs + sources = good.

> 
> > I am creating a static build, not a dll.
> 
> How do you handle installation-directory-independence? Currently it's
> the DLL's startup functions (DllMain) that find out where GLib, GTK+
> or Pango are installed, to find initialisation files, message
> catalogs, dynamically loaded modules, etc. Message catalogs are
> *important*.

Yes, that needs to be addressed still. GTK supports static building.
The building of the dll is the next step after the first round is
finished. Untill then, people will have to do without.

Right now there is not an easy way to build at all, not from the cross
compiler. When the dpackaging is all done, then we can tweak the
configuration. I hope to even centralize all the changes to the
debain/rule, libtool, autoconf, aclocal and configure.in into a single
file that is included by the other packages. THen sweeping changes can
be made.

> 
> Do you expect end users to install GTK+ in a fixed location that the
> person who builds a distribution according to your standard decides? 
> That is not a good idea on Windows. Or do you really expect Windows
> *end-users* to want to build GTK+ themselves? Even seasoned corporate
> NT administrators seldom have any ideas about building software from
> source. Sad, but true.

I am just doing the work to get the build clean and easy to use. To
produce static exectuables. If some features get broken, and the users
complain, then we will work to fix them. Right now we dont have all the
porting done.

The installation and distribution have not been convered yet. that has
to be looked into. As I said, the dpkg is not running %100 on cygwin
yet, but we should be able to use an installation tool instead for the
final distribution.

> (There is also the possibility to store the installation location of
> each package in the Registry (see the docs for
> g_win32_get_package_installation_directory()), but I would advice
> against using that. The DllMain method is more elegant and enables
> several independent installation of almost the same versions of some
> software on the same machine without having to make sure the
> installations look up differently named Registry keys.)
> 
> > That is why it is so hard to get all the sources. If we were to
> take
> > the gpl by the letter, you need to provide all the sources of all
> > the non-standard dlls that you have, the entire toolchain as I am
> > doing it with the binaries.
> 
> The www.gimp.org/win32/downloads.html page *does* provide sources for
> all the binaries on that site. 

>(If something is missing, it is by
> mistake.) But I am not going to provide copies of the sources (or
> binaries) for gcc, binutils, awk, sed, perl, make, libtool, autoconf,
> automake, and whatever else might be needed for a full auto*-style
> build of GLib or GTK+.

You just need to provide the sources for the non-standard libs you
need. The compilation tools are another issue. Read the faq i sent to
you.

> 
> If somebody (else) convinces me that the LGPL really requires it,
> sure, I can have copies of the binary and source packages for
> libtiff,
> libpng, etc there, too. But it does seem a bit silly, and causes
> unnecessary maintenance troubles.

As i said, I am setting up a package repository, we have 15 some
packages in there. Later i hope they will become part of the debian
distribution, there is a win32 distro in the works. 

My point is that I just want to get on with the porting, would like
some help testing, and would like a link on the page. I am setting up
the new package repository so that it is GPL compliant. 


I have told you my interpretation of the GPL, that, and the pain of
using the DIA on win32 is what motivated me to do this. I am not going
to make any more issues about it. Please let us just get on with the
work, please give my page a reference, and if anyone is interested in
the cross compiling of gtk, send them to me.

thanks,
mike



=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com