Wrong Vala typelib example

[inigomartinez]

g_ir_compiler = find_program('g-ir-compiler')
custom_target('foo typelib', command: [g_ir_compiler, '--output', '@OUTPUT@', '@INPUT@'],
              input: join_paths(meson.current_build_dir(), 'Foo-1.0.gir'),
              output: 'Foo-1.0.typelib',
              depends: foo_lib,
              install: true,
              install_dir: join_paths(get_option('libdir'), 'girepository-1.0'))

This example, located at Vala Reference, doesn't work and produces the following error message:

ninja: Entering directory `_build/' ninja: error: '../meson/_build/Foo-1.0.gir', needed by 'Foo-1.0.typelib', missing and no known rule to make it

The same example it's used in the vala gir example, althougth it's slightly modified and that makes it to work. This error doesn't happen when install and install_diroptions are not present.

[inigomartinez]

This issue may be related to #634 and #1014.

[nirbheek]

@arteymix wrote that. @TingPing might also be able to help.

[arteymix]

A correct solution would be https://github.com/valum-framework/valum/blob/master/src/vsgi/meson.build#L36 with the dependency on the library and the GIR explicitly in the command.

I also noticed that --shared-library has to be specified.

g_ir_compiler = find_program('g-ir-compiler')
custom_target('foo typelib', command: [g_ir_compiler, '--shared-library', foo_lib.full_path(),  '--output', '@OUTPUT@', join_paths(meson.current_build_dir(), 'Foo-1.0.gir')],
              output: 'Foo-1.0.typelib',
              depends: foo_lib,
              install: true,
              install_dir: join_paths(get_option('libdir'), 'girepository-1.0'))

With #1014 we would not need this hack.

[inigomartinez]

I've been porting gitg, an application written in vala, which also generates the GIR and typelib objects, and I faced the same problem again.

My mistake was that when writing the custom_target, I was including the generated GIR object path into the input parameter, which I was using later in the command with the @INPUT@ token. However, meson checks the existance of the input object, which is not already built in a clean build dir, and then fails.

In your approach, you use it directly as a command parameter, so meson does not check it and it works.

Actually what suprises me is that the GIR object target actually exists, so I don't understand why meson doesn't link them.

With #1014 we would not need this hack.

Probably, as you said, the best solution is a function that generates the object, but I'm worried about the objects (GIR, vapi) generated when calling at shared_library, as it's possible to build a path for them, as you know where they are created, but there isn't any returned object for them.

[arteymix]

The approach I'm suggesting is more a hack. The GIR object exists because of the dependency on the shared library, which ensures that valac has run before compiling the GIR.

Now that we have multiple indexing for custom targets #2376, it might make sense to add this to Vala targets so that we can index the GIR and have a proper argument for the input array.

The ideal solution is most definately a helper in the GNOME module, but I lack time for this :(

[raggesilver]

Any updates on fixing this issue (not the example but the custom target indexing)?

[mdegans]

Any updates on this?

[esodan]

This is related to #5968