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

Passing a dummy dependency to library() doesn't work #2872

Closed
lazka opened this issue Jan 4, 2018 · 7 comments
Closed

Passing a dummy dependency to library() doesn't work #2872

lazka opened this issue Jan 4, 2018 · 7 comments

Comments

@lazka
Copy link
Contributor

lazka commented Jan 4, 2018

Trying to pass a dummy dependency to library() I saw that it is suggested in the dependency() docs that one creates a dependency with name "" and required: false.

project('glib', 'c', 'cpp',
  version : '2.55.0',
  meson_version : '>= 0.44.0',
)
thread_dep = dependency('', required : false)
library('glib-2.0',
        dependencies: [thread_dep])

but this results in the following error:

Meson encountered an error in file meson.build, line 6, column 0:
Argument is of an unacceptable type 'Dependency'.
Must be either an external dependency (returned by find_library() or dependency()) or an internal dependency (returned by declare_dependency()).

What am I doing wrong?

@lazka
Copy link
Contributor Author

lazka commented Jan 4, 2018

Would a simple "declare_dependency()" have the same effect? (maybe the docs should recommend that instead if that's the case)

@nirbheek
Copy link
Member

nirbheek commented Jan 4, 2018

@jon-turney I believe your patch from #2615 caused this regression.

@lazka
Copy link
Contributor Author

lazka commented Jan 4, 2018

ah, the object returned by declare_dependency() returns true for found(), so that's not a viable replacement.

jon-turney added a commit to jon-turney/meson that referenced this issue Jan 4, 2018
Make not-found dependency object identically to prior to PR mesonbuild#2615
Extend test case to cover uses of the not-found dependency object

Fixes mesonbuild#2872

Also, prevent direct instantation of class Dependency, since
BuildTarget.add_deps() rejects that.

It might be better to fix BuildTarget.add_deps() and look for any other
similar problems...
jon-turney added a commit to jon-turney/meson that referenced this issue Jan 4, 2018
Make not-found dependency object identically to prior to PR mesonbuild#2615
Extend test case to cover uses of the not-found dependency object

Fixes mesonbuild#2872

Also, prevent direct instantiation of class Dependency, since
BuildTarget.add_deps() rejects that.

It might be better to fix BuildTarget.add_deps() and look for any other
similar problems...
@jon-turney
Copy link
Member

jon-turney commented Jan 4, 2018

Bother, that's a bit disappointing.

Not sure of the best way to fix this, so I created a couple of solutions as separate PRs.

@jon-turney
Copy link
Member

jon-turney commented Jan 4, 2018

I also notice that the test case given fails when using msvc and ninja backend, I think because library() is used with zero sources. I'll raise a separate issue for that.

@lazka
Copy link
Contributor Author

lazka commented Jan 6, 2018

Thanks @jon-turney!

@jon-turney
Copy link
Member

@lazka no problem

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

Successfully merging a pull request may close this issue.

3 participants