On 30/08/14 06:47, Matthew Brush wrote:
On 14-08-29 07:24 AM, Enrico Tröger wrote:
On 28/08/14 01:49, Matthew Brush wrote:
On 14-08-27 10:54 AM, Enrico Tröger wrote:
Am 24.08.2014 um 17:18 schrieb Matthew Brush:
On 14-08-22 11:23 AM, Enrico Tröger wrote:
Hi,
lately, I started building a new Windows installer which includes a recent GTK 2.24 runtime for Windows which need for future releases.
While most things went fine I noticed one problem:
GTK, in detail Glib, changed the way g_get_user_data_dir() works on Windows: in older releases, something GLib 2.28 or 2.26 and older, g_get_user_data_dir() returned c:\users<username>\AppData\Roaming, in newer GLib versions it returns c:\users<username>\AppData\Local.
This affects users who already have a config directory located in <...>\Roaming and Geany would look in <...>\Local now.
This is the change I'm talking about: https://git.gnome.org/browse/glib/commit/glib/gutils.c?id=9d80c361418f94c609...
How do we want to handle this?
- continue using the <...>\Roaming directory (and so not using
g_get_user_data_dir() anymore)
If we went this route we could use something like the attached patch[0]. Maybe it's what the linked commit is referring to about proper Windows programs probably not using those GLib functions?
- leave the code as it is, resulting in a new complete config for
users
- add some code to check if a config in <...>\Roaming exists and
if so, move it to <...>\Local
I was thinking about it a bit and it might be good to keep using the "Roaming" one (ie. whatever Win32 API gives as correct dir) since IIUC it allows users on a domain to sync their config between machines on login/logout. As mentioned in the linked commit, the function we use (g_get_user_config_dir()) only changed to match g_get_user_data_dir(), not because it's the actually a better or more appropriate directory.
Hmm, ok. We could do it this way either. I have no clue about this roaming stuff, just thought it might be good to follow GLib to be consistent with config dir location. But I don't mind much.
I'd implement this way first, based on your patch, and if we want, we can change to .../Local later anyway if desired.
I think it's probably the easiest solution, with the least code, and most compatibility. If you don't feel like coding it yourself, let me know and I can whip up a (real/working) function to do it. I've been doing a fair bit of Win32 API coding lately so it's fresh on my mind, I
I don't mind, if you like to do it, I'd be happy to test the result :).
just can't get Waf working with my new setup because Geany's git tree is not on the C: drive anymore (it's on a mapped/shared drive), which makes Waf choke with errors about "no init function" (have you ever experienced this error?).
Nope. I remember on a prevous Windows VM I had Geany and library includes and libs on a C: drive while the system itself (Windows, Python, ...) was installed on a E: drive. That worked well though both were local drives, nothing mapped.
How do you start waf? On my current setup, I added c:\python27 to $PATH, so in the Geany git clone I just type:
python waf configure python waf build python waf install
and everything works fine.
By trial and error (for lack of Waf documentation), I was able to get it working again. Based on observations alone, it seems that if wscript is in the root directory of a drive (ie. `X:\wscript`), it requires "init" and "shutdown" functions to be present in the wscript. All I could find online was some waf source code that provides default implementations for these functions, but for whatever reason that doesn't happen when the wscript is in root dir.
See attached patch for what got it going.
Should we commit this? IIUC, this is a workaround for the drive letter bug in Waf? And so these two functions are not needed anymore once the mentioned fix in Waf is released?
Regards, Enrico