Mail Archives: geda-user/2012/11/16/08:56:14
Bob Paddock:
> > Ok, let's rephrase a, to
> >
> > a, Tell the user <as above>
> > else he has to build from source.
> >
> > would that work ?
>
> No. Few users of Windows are developers.
> They would not even have a compiler let alone know what to do with it.
Ok.
> > 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;
> > }
> > }
>
> That will take a long time as it will have to wait for each
> non-existent network maped drive to fail.
> Even local drives could take time to fail depending on the version of
> Windows and their drivers.
Ok.
> > May the user still be able to build programs on such a system?
>
> Things do seem to be going in the direction of preventing that, tho we
> are not there yet.
>
> > 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?
>
> Could be done that way. Some USB open-source USB drivers take the
> approach of self-signing.
> That may not work some time in the future, I'd not worry about it today.
Ok.
> >> d. is the most Windows viable solution.
>
> > I haven't found anything c++ish in libgeda, should we still worry?
>
> Not today.
Ok.
But if we push the problem to the caller, geda is not any better off,
we have to solve it in the caller instead.
It should be better if the lib could have a get_localedir() routine and
provide it to the caller.
> > How do other programs handle this?
>
> I usually use the wxWidgets package for my Windows code and it has
> 'standard paths':
> http://docs.wxwidgets.org/2.8/wx_wxstandardpaths.html
> http://docs.wxwidgets.org/2.9.4/classwx_standard_paths.html
We cannot depend on that, but I found [1].
[1] http://developer.gnome.org/glib/2.28/glib-Windows-Compatibility-Functions.html#g-win32-get-package-installation-directory-of-module
> > So a fourth possibility could be:
> >
> > e, install geda things in some dir, so:
>
> As long as 'dir' is not hard coded that is fine.
> Installers will generally take care of setting that.
>
> > the binaries are in dir\bin
> > locale files are in dir\share\locale
>
> That works.
Then I consider this as the preferred choice.
> BTW. It is best to use forward slashs in source files for paths in
> source files.
> It is the Windows command processor that has issues with '/'.
> #include "x\y.h" works just as well as #include "x/y.h".
Ok, good.
Regards,
/Karl Hammar
-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
- Raw text -