[obijohn]

On Windows, makeAll wouldn't complete. After some checking, it turns out that building the library completed, but compiling the tests failed. So, I manually copied the gtkd.lib file to the d\dmd\lib folder (to make it easy for link to find it) and tried to compile HelloWorld.d. Well, it still wouldn't compile. After finally figuring out that advapi32 was the problem, and figuring out how to get it to link with advapi32, the program finally compiled. But then it wouldn't run, complaining about not finding the gtk dlls.

Well, this was odd because I do have gtk installed, and it's in my path. In fact, I have two other language bindings using gtk, and both of them work and find the dlls. So, I dug around the gtkD source and located the problem: the path to the Gtk dlls is hard-coded (for Windows). This is a bad idea. I have Gtk installed at C:\Gtk, not "C:\Program Files\Common Files\Gtk\2.0" or whatever god-awful location is chosen as the default. I think most developers have their own idea of what a good install location for a library should be, and most probably don't use the default location chosen by a setup program. Well, maybe saying "most" is pushing it, but I'm sure it's a large percentage.

I don't have it open right now, but I believe the file in question is load.d or loadpath.d or something similar. I changed the function that returns the library path to return an empty string so that the PATH environment is searched. That worked. Since the binary installation of Gtk for Windows adds it's install location to the PATH environment variable anyway, there is no need to hard-code the location in the source or search the Registry for keys, especially since other users might decide to install it in another more convenient location, or they may even install it from a zip instead of a setup executable and set the PATH variable themselves (like I did). At the very least, gtkD could use it's own environment variable to set the load path.

Anyway, after rebuilding gtkD with that fix, the resulting HelloWorld.exe file actually ran (yay). However, I did notice that it seemed to load all the gtk dlls, which it shouldn't because it just uses a frame and a label. The size on disk was about 500KB, but in memory it was over 8MB. A similar program using the gtkAda bindings, just using a frame and label, is a little over 3MB in memory once the dlls are loaded (and the regular Ada runtime is quite a bit larger than the D runtime), so I believe it has something to do with gtkD loading all the dlls instead of just what's needed. This is not that big a deal, I just thought I'd mention it as something to look into. I realize that any program of reasonable complexity will probably need all the dlls loaded anyway.

These issues aside, I think gtkD is an important project. I believe D needs a good cross-platform GUI package in order for it to gain more widespread acceptance, and gtkD looks like it's shaping up nicely.

[Pse]

I'm not the windows expert around here, but the recommended method for building gtkD on Linux is DSSS. Changes were implemented to get it to compile in Windows, so you may want to try that. "makeAll.sh" and "compd" should probably be considered deprecated unless someone steps up to maintain them.

[obijohn]

makeAll and compd are deprecated? Then I guess the Getting Started page should be changed, since it says "just run the included makeAll file". Also, makeAll and compd should be removed from the latest distribution if this is the case.

Building problems aside, the biggest issue for Windows is the hard-coded dll load path. First, hard-coding that path doesn't matter if another process has already loaded some of the gtk dlls, since those will be used instead. Second, if someone, including an end-user of the program being developed, has installed gtk to a different location, the program will never find the dlls even if they are in the PATH environment variable.

[JJR]

The windows version does need some work, that's a fact. No, the dll path should not be hardcoded as it is.... the current state was kind of a quick solution very early on that never really got fixed other than via the registry lookup method (which I think was added by Allan K. at a time he was contributing heavily to the project). I think that the registry method is actually a valid technique on win32, but it's greatest shortcoming is that it is only supported using Phobos. Therefore, I'm not really interested in maintaining that code.

I agree that hardcoding the path should be removed. Setting the path environment hopefully is reliable enough, but windows dll's are horribly subpar in their mechanism and versioning. It's already been a pain dealing with preloaded dll's that occur elsewhere. The user must be sure to put the rutime gtk libraries in the path first before any other occurences of the dlls. And then we also have to hope other gtk dll's (from some software that uses it's own versions) aren't currently loaded. I'm really unimpressed with the difficulties associated with loading the dll's created on win32. Clever and reliable solutions to this problem are welcome.

Nonethless, I actually think keeping it simple with a none-hardcoded dll load procedure is the best /simple/ solution for now. Also we will encourage the use of one supported gtk+ install runtime (see Trac wiki page)... and encourage users to make sure it occurs first in their path. But I still see the possibility of trouble, not so much for developers, but for end-users of the software products that make use of gtkD because of the problems associated with win32 dll's.

So please add a ticket for this change.

Concerning makeall and compd: they are not at all officially deprecated. It's just that a few of us (maybe a very few ) have been moaning and groaning about the confusion they cause (I've been one of those few). As Pse said, there hasn't really been much of a voice concerning support, improvement, documentation, and development of these tools either, so I see little point for them to stay. And I've said so on several occasions.

I would prefer it if we could just maintain dsss support and discontine compd and makeall to eliminate assumptions that they work properly (and to keep support to a single build mechanism). I don't know who is maintaining these build tools, but I know that I am not. For now they sit there cluttering the gtkd directory until something is done. So if someone is still using compd, please speak up and offer a solution for properly supporting and documenting them with gtkd.

Yes, I know these things remain in the wiki page of the project... but these can't really be removed until a decision is made about what is going on with gtkd. I'm hoping these things can be resolved soon. If they end up remaining unresovled for too long, I may just make an arbitrary decision on this. I'm really hoping this doesn't have to happen, though.

[JJR]

[Mike Wey]

There are a few other bindings that i konw of that require that the gtk bin dir is added to the PATH (Gtk2Perl, PyGTK and Ruby-Gnome2) that might also be a good option for GtkD.

[heromyth]

[Mike Wey]

[heromyth]

[Mike Wey]