[Groff] Re: GROFF for Windows

[MARSHALL Keith]

Hi Kees,

Thanks for your reply to my earlier query; I can fully appreciate the
reason why it was delayed -- sorry to hear that you became a victim of
heavy spamming.

As you have probably deduced, I have already resolved the questions I
originally posed, to my own satisfaction.  However, since your suggestions
differ from my own solutions, they certainly merit further consideration:

> 1. For installing groff in a location different from c:\progra~1\groff, 
I
> now use a batch file that sets the necessary environment variables
> (setgroff.bat). The new setup program adapts this batch file to the
> installation folder. It would be nice if groff would automatically look 
up
> the installation folder and search font and macro files from there. This 
can
> be done directly, by means of GetModuleFileName, as I have done for 
bison,
> enscript and other gnu packages. A more general way is provided in the
> gettext and libiconv packages. Unless you have already solved this 
problem,
> I am willing to look into it.

I resolved this by configuring groff with "--prefix=/my/install/path", 
which
works fine when building a local installation from source.  It clearly 
would
not work for a binary distribution, such as GnuWin32.  I have little 
personal
incentive for pursuing this further, but I am sure Werner would be willing 
to
consider your ideas for providing support for relocateability of a binary 
Win32
distribution, if you are able to develop them into the form of patches. If 
I
can be of any assistance in this, I am willing to help, but my time is 
limited,
and my knowledge of the Win32 APIs is practically nonexistent.

> 2. In the GnuWin32 port this has been solved, at least I hope so, by 
using a
> more general tmpnam function, which first looks in the folders pointed 
to by
> the environment variables TMP, TEMP and TMPDIR. In the groff sources 
this
> has now been solved by your own patches. Perhaps the code in 
xtmptemplate
> (tmpfile.cpp) may be shortened somewhat by opening the temporary files 
with
> mode _O_TEMPORARY (see
> http://msdn.microsoft.com/library/en-us/vclib/html/_crt__open.2c_._wopen.asp),
> which causes the file to be automatically deleted after it has been 
closed,
> so that there may be no need for maintaining a list (xtmpfile_list) of 
files
> to be deleted on exit.

While using _O_TEMPORARY may appear to simplify things for the Win32 
context,
it isn't portable, so it would actually complicate the tmpfile.cpp 
implementation,
in order to support both POSIX and Win32 semantics.  IMHO, since the 
existing
implementation works fine for both cases, we should leave it alone -- "if 
it
ain't broke, don't fix it".

Once again, thanks for taking the time to answer my original query.

Best regards,
Keith.