Mail Archives: geda-user/2012/11/15/16:10:12
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
- Raw text -