After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 732668 - Make g-ir-doc-tool work on Windows without using a MSYS shell
Make g-ir-doc-tool work on Windows without using a MSYS shell
Status: RESOLVED FIXED
Product: gobject-introspection
Classification: Platform
Component: general
2.41.x
Other Windows
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-07-03 09:19 UTC by Fan, Chun-wei
Modified: 2015-02-07 16:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
giscanner: Make _get_cachedir() work on Windows without an MSYS shell (1.22 KB, patch)
2014-07-03 09:25 UTC, Fan, Chun-wei
none Details | Review
giscanner: Make _get_cachedir() work on Windows without an MSYS shell (1.25 KB, patch)
2014-07-03 09:28 UTC, Fan, Chun-wei
committed Details | Review
giscanner/cachestore.py: Clean up a bit (1.03 KB, patch)
2014-07-30 06:12 UTC, Fan, Chun-wei
committed Details | Review

Description Fan, Chun-wei 2014-07-03 09:19:42 UTC
Hi,

In its current form, g-ir-scanner does not work on Windows outside a MSYS shell, so one is not able to use Mallard/g-i to generate documentation from a .gir file with Visual Studio builds of g-i.  This is caused by _get_cachedir() in scanner/cachestore.py as it attempts to get the user's home directory by querying the HOME env var, which does not exist in cmd.exe (which the Visual Studio builds will use), but will work in an MSYS shell.

I will attach a simple patch that will fix this, by querying HOMEPATH when we are building/using g-i from cmd.exe, so that we can get the correct home directory of the user, so that the documentation can be generated properly.
Comment 1 Fan, Chun-wei 2014-07-03 09:25:13 UTC
Created attachment 279825 [details] [review]
giscanner: Make _get_cachedir() work on Windows without an MSYS shell

Hi,

Here's the patch for the issue.  By running the doc tool tests in tests/scanner, I was able to get the doc files for all the C, Python, Gjs and section files that matches the respective expected outputs (albeit with different line endings, but this is a common Windows vs UNIX issue).

With blessings, thank you!
Comment 2 Fan, Chun-wei 2014-07-03 09:28:53 UTC
Created attachment 279827 [details] [review]
 giscanner: Make _get_cachedir() work on Windows without an MSYS shell

Hi,

Sorry, please ignore the previous patch, I had the old one there...

With blessings, thank you!
Comment 3 Colin Walters 2014-07-03 14:59:50 UTC
Review of attachment 279827 [details] [review]:

I'm not a Windows expert, but this looks reasonable to me.
Comment 4 Fan, Chun-wei 2014-07-04 05:09:10 UTC
Hello Colin,

Thanks for the review, the patch was pushed as 011b7c44.

Will close this bug now.

With blessings, thank you!
Comment 5 Simon Feltman 2014-07-04 05:52:55 UTC
It would be interesting to see if os.path.expanduser('~') works with msys?, I know it does on regular Windows and Linux...
Comment 6 Fan, Chun-wei 2014-07-25 02:26:05 UTC
Hello Simon,

This is what I get, supposing the user name is 'foo', under default circumstances, under MSYS given by mozilla-build:

c:/Users/foo

Under cmd.exe, I get C:\Users\fanc999.

Shall we use your recommendation instead?

For your references, with blessings.
Comment 7 Fan, Chun-wei 2014-07-25 02:27:44 UTC
(Sorry, the fanc999 should read 'foo' as well...)
Comment 8 Simon Feltman 2014-07-26 04:45:14 UTC
(In reply to comment #6)
> Shall we use your recommendation instead?

If it works as expected I think it is definitely better to let Python abstract the platform than re-doing it ourselves.
Comment 9 Fan, Chun-wei 2014-07-30 06:12:21 UTC
Created attachment 281997 [details] [review]
giscanner/cachestore.py: Clean up a bit

Hello Simon,

This is my patch for this based on your suggestions.  Please note that this is built on top of the previous patch as that patch was pushed previously as it was given A-C-N.

p.s.: By the way, any chance to look at bug 728313 (the build the g-i files using distutils bug), and possibly 732669 (the getting rid of the .def/.symbols files and using visibility/dllexport to export symbols bug)?

With blessings, thank you!
Comment 10 Simon Feltman 2014-08-01 06:33:02 UTC
Re-opening to consider new patch.
Comment 11 Simon Feltman 2014-08-01 06:34:56 UTC
Review of attachment 281997 [details] [review]:

Yay, three less lines of code and it's probably a more robust implementation.
Comment 12 Fan, Chun-wei 2014-08-01 07:27:58 UTC
Review of attachment 281997 [details] [review]:

Hello Simon,

Thanks for the reviews, the patch was pushed as 3701b320.

Will close this bug shortly.

With blessings.
Comment 13 André Klapper 2015-02-07 16:49:45 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]