Re: guile-2.0 on mingw: the sequel

[Mark H Weaver]

Eli Zaretskii <address@hidden> writes:

>> Date: Sun, 25 Aug 2013 19:24:17 -0400
>> From:  <address@hidden>
>> Cc: address@hidden
>> 
>> On windows, I think you call GetModuleFileName() with the handle that was 
>> passed to DllMain().
>> Is it possible for libguile to do that?
>
> I see no reasons why not.

Yes, that much we can agree on.  Since the Windows API provides a
reliable method to tell us the location of the libguile library, we can
certainly use that to find the rest of the Guile installation.

>> On a POSIXy system, there are shared places for config files,
>> libraries, documentation, and so on.  It's just different.  I don't
>> see why we would need to be "relocatable" here.
>
> One reason to be "relocatable" is to be able to easily run
> applications from the build or source tree, while a different version
> is installed on the system.

We already have a solution for this.  Just run "meta/guile" from the
build directory, or more generally "meta/uninstalled-env".

>> From: Mark H Weaver <address@hidden>
>> Cc: address@hidden,  address@hidden
>> Date: Sun, 25 Aug 2013 17:42:27 -0400
>> 
>> Eli Zaretskii <address@hidden> writes:
>> 
>> > We can provide an API for passing to the library the root of its
>> > installation.
>> 
>> I suppose, but that assumes that the main program knows the location of
>> the libguile installation it's linked to.  How would it know this?
>
> We are talking about the situation where libguile is _not_ installed
> in the usual places.  Why would a program _not_ know where that is?

I explained that in the part of my message that you omitted from your
quotation.

I can think of one notable case where the program would know where
libguile is located: when the program bundles its own copy of Guile, and
therefore assumes that libguile and the program are always moved
together as an atomic unit.

This practice is frowned upon on most POSIX systems (and rightfully so),
but I guess it's fairly common on Windows and MacOS X systems.

In cases where libguile is installed independently, and where libguile
has been moved since the program was built, there's no reason why the
program would know where libguile is located.  Every time the program is
run, the dynamic linker searches for libguile in many different places.
The set of places it looks depends on the platform.

>> > And btw, how is this different from GCC looking for its libgcc or GDB
>> > looking for its Python scripts?
>> 
>> GCC and GDB are programs, not libraries.  Finding out the location of
>> the current executable is a much easier problem than finding out the
>> install prefix of a particular library.
>
> The issue is how to find the auxiliary files _given_ the location of
> the executable, not how to find where the executable itself lives.

Yes, and those executables (GCC and GDB) can reasonably assume that
their auxilliary files are always installed in the same prefix as the
executables, since they are part of the same package.

However, libguile and some-program-that-uses-libguile are _not_ part of
the same package.  There's no reason to assume that they'll be installed
in the same prefix, and they could be moved independently of each other.

When the program is compiled, of course it needs to know where libguile
is located, but since we're talking about making these packages
relocatable, there's no guarantee that libguile will be in the same
place as it was when the program was compiled.

>> > And when it doesn't work, we didn't lose anything, we are just back to
>> > where we are now, right?
>> 
>> I disagree.  If we advertise a new feature that cannot work without
>> making dubious assumptions, then we're making promises we can't keep.
>> That's a step in the wrong direction, IMO.
>
> My turn to disagree.

Okay, again: How exactly do you suggest we determine the location of the
libguile installation from an arbitrary executable that links to it?

     Mark