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=9d80c361418f94c609840ec9f83741aede7e482c >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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 -- Get my GPG key from http://www.uvena.de/pub.asc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel