RE: [Gcl-devel] RE: Getting full pathname of running executable

[Mike Thomas]

Hi Camm.

| Hi Mike!  Thanks as always for your tremendous efforts!
|
| "Mike Thomas" <address@hidden> writes:
|
| > Hi Camm.
| >
| > The reason the new 2.6.1 didn't work today is that I discovered
| that the new
| > "make install" hard-wired *system-directory* code has broken the Windows
| > installer, which runs saved_gcl on the target machine during
| installation to
| > write out bat and sh startup scripts in the new bin directory.
| >
|
| Please accept my apologies.

No need for apologies - it's my fault for not being able to keep up with
your prodigious output!


| > The scripts actually refer to *system-directory*, expecting it to be set
| > correctly on the target machine, rather than referring to the machine on
| > which the installer was built.
| >
|
| OK, there have been two pathname related changes recently:
|

... Details (thanks) elided ...

| I'm not sure about the details of your installer's construction, but
| can't you get the right setting via the $(INSTALL_LIB_DIR) make
| variable?  The relevant makefile snippet is (of course)
|
|       cd $(DESTDIR)$(INSTALL_LIB_DIR)/$(PORTDIR) && \
|               mv $(FLISP)$(EXE) temp && \
|               echo "(setq si::*system-directory*
| \"$(INSTALL_LIB_DIR)/$(PORTDIR)\")(si::save-system
| \"$(FLISP)$(EXE)\")" | ./temp && \
|               rm -f temp

The problem here is that I am providing a Windows binary installer which
runs independently of the make system on the target machine.  During
installation, it runs GCL on the end-user machine to set up the batch
files/shell scripts which launch GCL.   The hard wired system directory now
interferes with that process.

I have been building the installer from an installed version of GCL on the
build machine (ie "make install", followed by an installer building program
which copies the files from the installed tree into the end-user installer).

Maybe I need to rethink that approach and build the installer directly from
the built source tree.

Your plan to allow GCL to run properly without having the location set by a
launching script is a Good Plan (TM).  On Windows, executables are normally
expected to work out those kinds of details for themselves which is why the
machinery is provided in the Win32 library.

| > Please pardon my ignorance of the semantics of argv[0], but
| what is wrong
| > with the code in "o/main.c" which has been up until now setting the
| > executable path dynamically (and correctly on Windows at least)?
| >
|
| The problem with the old setup is that if someone saves a local image,
| they still expect to be able to compile, load, describe and save from
| that image itself.  We need some way of finding the other installed
| files, as well as the running executable image.  Actually, I now see
| that we still have work to do in this area with *lib-directory* and/or
| *load-path* and *info-paths*.  I'll put this on the TODO list.
| Suggestions of course always welcome!

I understand.  My problem at the moment is finding the time to think!

| > Where were you planning to put the new code discussed last week
| (included
| > below)?
| >
|
| Would you like me to?  I thought it might be better if you test it
| first and then commit it if OK, since you have the working Windows
| compile setup.  In general, I get nervous about changing anything with
| a mingw (or xBSD, macos, ...) filename :-).  This snippet should go in
| a GET_FULL_PATH_SELF macro in your .h file.

It is better that I do it in theory at least.  I asked because I didn't want
to interfere with your plans by putting the code in the wrong place!

I'll whack that macro in for MinGW32 sometime this week.  I missed it in my
rush on Friday.

Cheers

Mike Thomas.