GIR file contains true/false

[Val Packett]

I'm not sure how g-ir-scanner handles ifdefs… does it just include all of them?

    <constant name="false" value="0" c:type="false">
      <source-position filename="../include/graphene-macros.h" line="77"/>
      <type name="gint" c:type="gint"/>
    </constant>
…
    <constant name="true" value="1" c:type="true">
      <source-position filename="../include/graphene-macros.h" line="78"/>
      <type name="gint" c:type="gint"/>
    </constant>

I don't think these should be there?

[Emmanuele Bassi]

I'm not sure how g-ir-scanner handles ifdefs…

g-ir-scanner runs twice: the first time, it works like the C pre-processor; the second time, it parses the macros.

I think it's picking up the true and false constants from stdbool.h—unless you're building Graphene with a MSVC toolchain that does not have stdbool.h, in which case it's picking them up from graphene-macros.h, alongside the typedef int bool.

The symbols are going to be namespaced, and don't really hurt anybody; if you're using a language with a boolean type and constants, you'll use those anyway.

So I guess my question would be: why is that a problem for you?

[Val Packett]

crystal-gobject generates code like false = 0 for this and that's not valid code in crystal. (See the "mentioned this issue" link above.)

gir-to-d did not generate anything for these constants, so maybe the implementation should handle this… oh well :(

[Emmanuele Bassi]

I guess it might be a good thing to filter out true and false constants in the introspection scanner itself; you may want to file an issue there.

[Emmanuele Bassi]

Actually, let's re-open this. It seems that the scanner will sill trip onto the symbols even if they are guarded by MSVC macros, so we should skip them properly.