Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't use shared_library in custom_target command #4892

copelnug opened this issue Feb 6, 2019 · 5 comments

Can't use shared_library in custom_target command #4892

copelnug opened this issue Feb 6, 2019 · 5 comments


Copy link

copelnug commented Feb 6, 2019


foo_lib = shared_library(...)
build_by_default: true,
command: [python3, extractDebugScript, foo_lib],
output: []


Traceback (most recent call last):
File "c:\program files (x86)\python36-32\lib\site-packages\mesonbuild\", line 112, in run
return options.run_func(options)
File "c:\program files (x86)\python36-32\lib\site-packages\mesonbuild\", line 230, in run
File "c:\program files (x86)\python36-32\lib\site-packages\mesonbuild\", line 161, in generate
File "c:\program files (x86)\python36-32\lib\site-packages\mesonbuild\", line 210, in _generate
File "c:\program files (x86)\python36-32\lib\site-packages\mesonbuild\backend\", line 225, in generate
self.generate_target(t, outfile)
File "c:\program files (x86)\python36-32\lib\site-packages\mesonbuild\backend\", line 326, in generate_target
self.generate_custom_target(target, outfile)
File "c:\program files (x86)\python36-32\lib\site-packages\mesonbuild\backend\", line 508, in generate_custom_target
(srcs, ofilenames, cmd) = self.eval_custom_target_command(target)
File "c:\program files (x86)\python36-32\lib\site-packages\mesonbuild\backend\", line 893, in eval_custom_target_command
raise RuntimeError(err_msg.format(str(i), str(type(i))))
RuntimeError: Argument <SharedLibrary 25a6634@@foo@sha: foo.dll> is of unknown type <class ''>


It is necessary to use foo_lib.full_path() instead. This is different than what work for executable.
Also, foo_lib should be added to depends of custom_target.

Copy link

QuLogic commented Mar 28, 2019

You should pass it using @INPUT@, I believe:

  build_by_default: true,
  command: [python3, extractDebugScript, '@INPUT@'],
  input: foo_lib,
  output: ''

Copy link

@QuLogic Your suggestion didn't work for me. The only thing that worked was something like

  build_by_default: true,
  command: [python3, extractDebugScript, foo_lib.full_path()],
  input: foo_lib,
  output: ''

Copy link

This is a special case of #1848. I also found this via trying to build a .typelib for a shared library (issue #5968). As mentioned in #2296, #1848 or #5968, the documented example of using a built file as custom_target input: does not work. I get that, using "file objects" for that makes conceptual sense, even though it's quite a paradigm shift when coming from make where the file names are the primary objects to work with.

But then there's still an impedance mismatch: shared_library() does have four outputs, but (1) it is rather hard to see them -- the only way I found was to drop one of the arguments in install_dir: [true, true, true, true]), and read them from the error message:

ERROR: Target 'umockdev' has 4 outputs: ['', 'umockdev.h', 'umockdev-1.0.vapi', 'UMockdev-1.0.gir'], but only 3 "install_dir"s were found.

Then I would expect to do something like this:

umockdev_lib = shared_library(...)

custom_target('UMockdev-1.0 typelib',
  command: [g_ir_compiler, '--output', '@OUTPUT@', '-l', '', '@INPUT@'],
  input: umockdev_lib[3],
  output: 'UMockdev-1.0.typelib',
  install: true,
  install_dir: get_option('libdir') / 'girepository-1.0')

But that doesn't work:

../ ERROR: Tried to index an object that doesn't support indexing.

I also tried to put the indexing into the command line:

  command: [g_ir_compiler, '--output', '@OUTPUT@', '-l', '', '@INPUT3@'],
  input: umockdev_lib,

but that doesn't work either:

ERROR: Command cannot have '@INPUT3@' since there are only 1 inputs

i. e. you only see the built .so, not the auxiliary outputs (.gir, .h and so on).

So I think this amounts to a design decision: Does meson want to chain builds with file objects or file names? In the former case, please provide proper output objects, in the latter case, re-enable input: 'filename' if filename is the output of some other rule.


Copy link

jpakkane commented Nov 7, 2020

Any particular reason why you are building typelibs by hand rather than using the builtins in the Gnome module?

Copy link

@jpakkane : The Compiling Vala applications and libraries documentation says to use custom_target() (That documentation does not work due to said input: meson.current_build_dir() / 'Foo-1.0.gir', but at least to me the most obvious way how to fix it was to avoid input:.). I wasn't even aware of gnome.generate_dir(), thanks!

But also, (1) I need to post-process the .gir as Vala does not support explicit annotations (I need a Rename-to:), and (2) generate_dir() seems to be tailored towards a C library. My library is written in vala, and valac already generates the .gir file -- I just need to build the .typelib for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

5 participants