meson can't find python3 dep because of how python are packaged on gentoo. See URL for more info. Reproducible: Always Steps to Reproduce: 1. Convert dev-libs/libratbag ebuild to 9999 2. Try to emerge it
https://github.com/libratbag/libratbag/blob/575b7bce98800efc11bd2e7ecf065aced391580d/meson.build#L544
Are you properly using the python-r1 or python-single-r1 eclass? The python_setup function found there should take care of setting up an appropriate python3.pc file.
(In reply to Mike Gilbert from comment #2) > Are you properly using the python-r1 or python-single-r1 eclass? > > The python_setup function found there should take care of setting up an > appropriate python3.pc file. My ebuild is not used this eclass at all, added eclass and python_setup, now configuration works. Should i close this issue now?
I think, that bug should be open. You are right, that in an ebuild environment the appropriate file is set, but what about building a project in your home. If you use meson (for your own project) and Gentoo and the meson.build contains: ``` dependency('python3') ``` it will not work. Chaning it to e.g. ``` dependency('python-3.6') ``` does work, but not on other distributions. Proposal: Let `eselect python` provide a python3.pc file as well.
I did it manually now and it works: ``` ln -s python-3.6.pc /usr/lib64/pkg-config/python3.pc ```
(In reply to gerion from comment #4) > I think, that bug should be open. You are right, that in an ebuild > environment the appropriate file is set, but what about building a project > in your home. > > If you use meson (for your own project) and Gentoo and the meson.build > contains: > ``` > dependency('python3') > ``` > it will not work. > > Chaning it to e.g. > ``` > dependency('python-3.6') > ``` > does work, but not on other distributions. > > Proposal: Let `eselect python` provide a python3.pc file as well. Upstream python3 ships a python3.pc symlink to python-$(VERSION).pc, which seems to be shipped by most distributions. This thus seems to be a Gentoo-specific issue. It doesn't cause any problem for packages compiled through portage, but when manually compiling a package, it prevents python3 from being found by pkg-config. Given that upstream ships the file, and that packages in the wild depend on it, letting `eselect python` provide a python3.pc symlink appears a good idea to me.
That seems like a reasonable enhancement for eselect python. Please file a bug and/or submit a patch if you would like to see it.
Figure out how to do it without writing to /usr and I'll be happy to merge. And no, symlink to symlink is not a solution.
(In reply to Michał Górny from comment #8) > Figure out how to do it without writing to /usr and I'll be happy to merge. > And no, symlink to symlink is not a solution. Why is writing to /usr a problem ? There are other eselect modules that do so (kernel comes to mind, to update the symlink to the kernel sources in /usr/src/). Can we reopen this bug ? We may not have a straightforward solution (assuming there are reasons why we can't write to /usr), but it doesn't mean the issue is invalid.
(In reply to Laurent Pinchart from comment #9) > (In reply to Michał Górny from comment #8) > > Figure out how to do it without writing to /usr and I'll be happy to merge. > > And no, symlink to symlink is not a solution. > > Why is writing to /usr a problem ? There are other eselect modules that do > so (kernel comes to mind, to update the symlink to the kernel sources in > /usr/src/). I'd argue that this is okay because if you installed the sources there in the first place, you're clearly okay with updating /usr, I suppose. Not that I'm fully sure of the arg here. The idea is /usr may be immutable and/or shared across systems (e.g. ostree nowadays). > > Can we reopen this bug ? We may not have a straightforward solution > (assuming there are reasons why we can't write to /usr), but it doesn't mean > the issue is invalid.
