Re: [gnome-db] Compiling libgda on win32 with MinGW/MSYS

[Brecht Sanders <brecht sanders org>]

> > > You can also use the programs in the "tools" directory:
> > > * gda-diagnose will produce HTML about a lot of things (this is
> > > probably the first one you want to try)
> >
> > Here I get an error popup: "Gda-ERROR **: Error opening directory
> > '......../lib/libgda-3.0/providers': No such file or directory
> > aborting..."
> > This is probably because I install to a temporary location before
> > packaging the Windows version, and then install it to the final
> > location.
> > I do this because on Windows you can't assume the exact absolute
> > location at compile time.
> > Is there any way to tell libgda where to look for its providers?
>
> No, there is not, the paths to the providers' directory, or to the
> config or ressources files are hard-coded at compile time (based on
> the --prefix specified when configuring).
>
> Of course it would be possible to test for the existence of a global
> GDA_HOME or similar environment variable and use it as a if that was
> specified as the --prefix spec.
>
> Another possibility would be to borrow some code from the autopackage
> project which make it possible to discover at runtime the real
> directory from which the applications are run, and then automatically
> adjust the directories. This would have the side effect of making the
> whole thing relocatable transparently.
>
> What do you think?

I think having the providers hard-linked is very unflexible and will certainly be
an issue on Windows, because there even the directory Windows is installed in
can't be assumed to always the same.
Also typically Windows installers will give a choice to the users where they want
to install things. One of the reasons is that Windows uses drive letters instead
of mount points, and if a certain drive is getting too full you should be able to
install somewhere else.

The global environment variable also doesn't appeal to me very much, because then
you would need to set this globally in the Windows settings.

I don't know the autopackage project, but what I have done in the past is just use
the running executable as reference point.
I believe I got the name of the running executable with _argv[0] (_argv is a
global variable present on win32 that is exactly like the argv parameter in a
normal main function). Then I strip everything after the last backslash to get the
base directory where I load files like shared object (.DLL) or other resources.
This is the cleanest solution in my opinion because it allows creating
applications that don't need to change system settings or the Windows registry.
This is also needed if you want to make applications run off removable media (a
realistic example being a CD-ROM with an sqlite database).

Maybe even better might be to also look relative to the location of the running
libgda (currently called libgda-3.0-3.dll on win32), but at this time I haven't
search yet how this is done (my firtst guess is making a DllEntryPoint function
that stores the path in a global variable).

So it might be a good idea to expand the current situation of 1 fixed path to a
search path sort of thing, where a list of directories can be searched in when a
shared object needs to be loaded.

Do you think this is a lot of work to implement?