Re: Makeing librsvg work (bizp2.dll missing)

[Tor Lillqvist <tml iki fi>]

> If there is no official installer provided by the GTK project, everybody
> has to bundle GTK by himself.

Don't overuse the term "official". In Open Source volunteer-based
work, whoever starts doing something, and doesn't give up, and gets
others to use his/her work, gets to call it "official". It's not like
the GTK+ Steering Council (if such a thing existed) had given the task
of building Win32 binaries to somebody (me) and prohibited others from
doing Win32-related things, for instance installer work. If just one
person of these "everybody" you mention would make their work generic
enough, would make it available to others, accept patches etc, that
could become equally "official".

> I would prefer to include an existing GTK installer for my software, but
> there is no one I can rely on (see my other posting the last week).

I honestly don't understand this argument. As I have mentioned,
installing GTK+ doesn't require anything except plopping the selected
files (those DLLs the app needs, message catalogs if needed, theme
files if needed) into place in their original relative location under
the installation directory. So all that is needed is to list the files
and tell their source locations and destionation locations to the
installer-builder.

Now, for the application's *own* files, presumably the same is needed.
Especially for applications ported from UNIX (I don't really think
many people write Windows-only apps with GTK+), the app usually has
makefilery that enables one to run a "make install" to produce the
source tree from which to pick files into the installer.

So basically if one automates that (writes a script that traverses the
"make install" destination and produces the input file for the
installer-builder), the same automation can be used to also tell the
installer-builder about GTK+.

And even if one does not automate it, surely it is not a big deal to
list a couple of folders that should be included (recursively) in the
installer.

> These are "only" four sub-installers. Not that much work for those who
> are knowledgeable to write installer-scripts.

But the four mentioned used widely different "scripts". If one wanted
to provide something that could be used by all four, one would in fact
have to invent a fifth "meta-sub-installer" source format and a four
translators...

--tml