Re: gtkmm on Windows: Last steps



On Sun, 2008-10-19 at 15:40 +0200, Murray Cumming wrote:
> It looks like we are almost done with the gtkmm on Windows effort. I
> have just a couple of questions:
> 
> 1.
> http://live.gnome.org/gtkmm/MSWindows
> says
> "make sure the "Add the gtkmm runtime directory to the PATH variable"
> option is checked. This is required for Windows to find the gtkmm DLL
> files."
> But:
> 
> 1.1
> If you should make sure that it is checked, why is it an option? The
> page should tell us how to make the decision.

Isn't the following clear enough?

"If you know what you do, then you can also uncheck that option. This
can be useful if you have multiple versions of gtkmm installed (for
example, both runtime and development DLLs) and want to choose which one
to use by setting the PATH variable manually."

Yes, it's actually an option for advanced users. That's why it's checked
by default and the wiki page says only to change it if one knows what
she does.

It also makes sure users notice that we change the PATH variable. This
can help them when testing redistribution packages (it doesn't make
sense to test whether an application runs out of the box if all the
required DLLs are in the PATH anyway).

People could also want to only set the PATH in msys so it does not
affect the global system, but only the msys environment.

So personally, I see enough use cases to justify to keep this option. If
others feel different about it, please tell us.

> 1.2
> I thought that applications would find the DLLs because they are in the
> same directory. Why is something in the PATH environment variable also
> needed? I don't understand why MS Visual Studio would need it either if
> we are using these "property pages".

MSVC++ does not need it to build stuff, but to run or debug from within
the IDE. I'm not sure whether there is an option in MSVC++ to extend the
DLL search path that the property pages could set, but I'll check.

If people do redistribute gtkmm with their applications, then it is not
necessary to set the PATH variable. However, the main purpose of the
runtime installer is to allow running applications that do not
redistribute gtkmm.

It might be debatable whether we would like to support that or not. An
option would be only to provide a development installer and tell people
to strip the MinGW binaries before redistributing. But that's also a bit
dangerous since stripping some libraries such as libxml2.dll breaks
them. Maybe this is because they have been built with MSVC, but I'm not
sure. So it's not as easy as "strip *.dll". We would need to make clear
which libraries to strip and which not.

> 2.
> The wiki page should make it clear that the runtime-only installer
> installs stripped (no debug symbols) for mingw, but that the non-debug
> DLLs are the same for other compilers, because it is harder for build
> systems to automatically choose between stripped and debug versions on
> that platform.

I clarified this on the Wiki.

> We should make it clear that it's probably the stripped
> DLLs that you want to redistribute with your application.

That's already mentioned in the Redistributing section. "If your
application is built with MinGW, you should use the files from the
runtime package, since they don't contain debug symbols."

> 3.
> Have we yet found a use for the silent install? If not, why do we
> mention it?

People have asked for it on the mailing list, so I added it to the Wiki
page. I do think it's good in general that this is documented somewhere
since there are few other options to find out the available flags. I'm
not sure whether people are actually using silent install or not, but
maybe others can comment on that.

> 4.
> Would someone like to update this section in the gtkmm book (in the
> gtkmm-documentation module in svn), and just refer to the live.gnome.org
> page where appropriate, instead of repeating:
> http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/sec-windows-installation.html
> Otherwise we'll have to remove it.

I'll have a look.

Armin



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]