| Summary: | dev-util/meson can't find python3 dep | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | tsmksubc |
| Component: | Current packages | Assignee: | William Hubbs <williamh> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | gstreamer, mgorny, python |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://github.com/mesonbuild/meson/issues/2504 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
tsmksubc
2017-10-20 08:35:05 UTC
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. |
