X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-18) with nmh-1.3
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: inbox
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] Bug #903129 Translations don't work on Windows
In-reply-to: <CAOuGh89nhtaPkKZ+0CJGn9V_XnZyi6YD-NndT53FHoAyYD0LFw@mail.gmail.com>
References: <20121113211401 DOT 20747813A49B AT turkos DOT aspodata DOT se> <CAOuGh89nhtaPkKZ+0CJGn9V_XnZyi6YD-NndT53FHoAyYD0LFw AT mail DOT gmail DOT com>
Comments: In-reply-to Bob Paddock <graceindustries AT gmail DOT com>
   message dated "Wed, 14 Nov 2012 09:57:46 -0500."
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Message-Id: <20121115210903.90A4881345E3@turkos.aspodata.se>
Date: Thu, 15 Nov 2012 22:09:03 +0100 (CET)
From: karl AT aspodata DOT se (Karl Hammar)
X-Virus-Scanned: ClamAV using ClamSMTP
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

Bob Paddock:
> > a, Tell the user he must install the binary in <dir> if he wants locale
> >    support, or just install it there without user intervention
> 
> Corporate IT policy's in the IT world make that non-workable.
> For example IT allows nothing to be installed on drive C:\
> to make *their* jobs easier.
> Some other places only allow user code to be installed in
> IT specified locations.

Ok, let's rephrase a, to

a, Tell the user <as above>
   else he has to build from source.

would that work ?

or the code could just do MS-windows equivalent of

char localedir[100] = "C:\\some\\path";
int cc;
for (cc = 'C'; cc < 'Z'; cc++) {
	struct stat sbuf;
	localedir[0] = cc;
	if (!stat(localedir, &sbuf) && S_ISDIR(&sbuf) {
	  break;
	}
}
if (localedir[0] > 'Z') failure();
else {
	bindtextdomain(...);
}

 i.e. use any drive, but install to <\some\path> on that drive.

would that work?

> > b, binary patch the lib at install time
> 
> That will run afoul of the day when signed binaries are forced on Windows
> users.
> Might not be far away in Windows-8.

May the user still be able to build programs on such a system?
If so, the install script might do a "final link" of the lib adding and
compiling a simple 'const char libgeda_locale[] = "..."' source file to the 
lib, then *sign* it and install it. Would that be possible?

> > d, since libgeda isn't really a freestanding lib, and the caller could
> >    possible also need some language files, push the problem to caller.
> >    E.g. by a parameter: libgeda_int(char *localedir);
> 
> d. is the most Windows viable solution.
> 
> Something to watch-out for when, if, we get there, is that there is a C
> locale and a C++ stream locale,
> and currently in MinGW setting the C++ stream locale slows the code down by
> orders of magnatudes.
> Hopefully that is fixed in the MinGW end someday.

I haven't found anything c++ish in libgeda, should we still worry?

///
How do other programs handle this?

http://blog.gmane.org/gmane.comp.windows.gnu.user/month=20080401

Says:

 second post:

The approach I have taken in software I have ported to Windows is to have a
DllMain() function (in case the software is a library, built as a DLL) store
the HMODULE for the DLL, and then when pathnames for things like message catalogs
or configuration files are needed, construct such pathnames at run-time, based
on the location of the DLL as retrieved using GetModuleFileName() function.
Typically, to minimize the impact on the source code, I then put in some header
something like:

 fifth post:

1) Identify the executable path name, using the global _pgmptr variable.
2) Strip off the final file name component from resultant path name.
3) If the new final directory name component is either `bin' or `sbin' (ignoring
case), then also strip that off.
4) Append `/share/locale' to the remaining path name.
5) Select message catalogues identified as `%L/%N' [*], within this directory
tree.

In any case, this logic is encapsulated within my port of `catopen()' itself,
so client applications need only to arrange to install their message catalogues
within a `./share/locale' subdirectory of their own installation tree, to ensure
that they will be found at run time.

///

So a fourth possibility could be:

e, install geda things in some dir, so:

  the binaries are in dir\bin
  locale files are in dir\share\locale 

  then, libgeda can find its localedir by the "fifth post" method above.

Regards,
/Karl Hammar

-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57