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
foo.vapi files generated by Vala library() should be installed #891
Comments
The best way to install them is via I just do: library('foo', 'foo.vala')
install_data(meson.current_build_dir() + '/foo.vapi', install_dir: 'share/vala/vapi') I also think we should install GIRs, headers and other files this way. We should update the Wiki about this. |
I think it's dangerous to start adding |
Here what I suggest for the Wiki (section Installing VAPI and GIR files): To install generated VAPI and GIR files, one can use install_data(meson.current_build_dir() + '/foo.vapi',
install_dir: 'share/vala/vapi')
install_data(meson.current_build_dir() + '/foo@sha/Foo-1.0.gir',
install_dir: 'share/gir-1.0') The |
No, this
|
I still think that |
How would you add a dependency between the target that builds the file and the install rule that installs it? |
Two target cannot build the same file, so there's a unique target that produce the file we want to install. It's either implicit (given that we've stated all the output already) or via a |
I don't think installing VAPI by default is a good idea because there's many situation where you don't wait it installed:
I would agree to have this behind |
Sure, let's not install vapi by default. That makes sense.
|
Also, how do you tell |
@nirbheek I actually just pass the output That's why I would love to see something like: library('foo', 'foo.vala', vala_vapi: 'foo.vapi')
install_data('foo.vapi', , install_dir: 'share/vapi', from_build: true) Jussi suggested something like foo_lib = library('foo', 'foo.vala', vala_vapi: 'foo.vapi')
install_data(foo_lib.out('foo.vapi'), install_dir: 'share/vapi') The returned file from We already have I would keep primary output installable by the target though and we should always prefer tools that produce a single output to make them composable (relate somehow to currying). |
Hmm, I like the You've changed my mind; |
In the end, we will support installing pretty much anything without additional arguments, as long as it is a well-defined target output. You should also ensure that |
I disagree. I think it's fine to install secondary outputs via |
Ok, but how will you prevent me from doing Maybe we should name |
I think if people do that ,we should just error out telling them to use the target itself. |
(and then the target itself won't work in |
I think the
I thought about allowing globs for this, but that's a slipper slope that we should avoid unless there's a compelling use-case. |
Wouldn't adding extra function to the build target object be nicer? Having something like language-dependant accessors to get specific compiler output. The
|
You may be right. For instance, the import library on Windows is compiler-dependent. With MinGW/GCC it's |
On the other hand, we should also think about how this squares with |
Should things like |
This is done in a horrendously hacky way for the time being. We really need accessor functions for target outputs to do it more cleanly, so we could call .vala_gir() on the libtracker_sparql target object and get the actual GIR output. See mesonbuild/meson#891
Not sure if we want to put this behind an option, but I vote that we just install it unconditionally for now. Can add an option later if people ask for it.
Found while investigating #890
The text was updated successfully, but these errors were encountered: