[Geany-Devel] Windows GTK Runtime 2.24 and config directory

[Matthew Brush]

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.

Cheers,
Matthew Brush

-------------- next part --------------
A non-text attachment was scrubbed...
Name: waf_funcs.patch
Type: text/x-diff
Size: 267 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20140829/0d5e183e/attachment.patch>