cuda_toolkit_version returns the version of dev-util/nvidia-cuda-toolkit
cuda_cudnn_version returns the version of dev-libs/cudnn
cuda_add_sandbox adds the nvidia dev nodes to the sandbox
Signed-off-by: Jason Zaman
---
eclass/cuda.eclass | 42 ++
1 file ch
cuda.eclass is only used from EAPI5,6 currently so remove support for
older EAPIs.
Updating to EAPI7 means removing versionator. It was only used to sort
the cuda versions. Instead first try the current GCC version, if that
fails try best_version, if that still fails just pick the last in
the list
Signed-off-by: Jason Zaman
---
eclass/check-reqs.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/check-reqs.eclass b/eclass/check-reqs.eclass
index d1ed395c8b1..689944c8770 100644
--- a/eclass/check-reqs.eclass
+++ b/eclass/check-reqs.eclass
@@ -7,7 +7,7 @@
Reported-by: Michael Orlitzky
---
glep-0066.rst | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/glep-0066.rst b/glep-0066.rst
index a605cf2..0720ada 100644
--- a/glep-0066.rst
+++ b/glep-0066.rst
@@ -4,10 +4,10 @@ Title: Gentoo Git Workflow
Author: Micha
On Mon, 2018-09-17 at 22:52 -0400, Michael Orlitzky wrote:
> On 09/16/2018 02:59 AM, Michał Górny wrote:
> > Hi, everyone.
> >
> > Just FYI: the Trustees have approved GLEP 76 aka our new copyright
> > policy [1]. While the exact implementation details are to be determined
> > yet, please note th
On 09/16/2018 02:59 AM, Michał Górny wrote:
> Hi, everyone.
>
> Just FYI: the Trustees have approved GLEP 76 aka our new copyright
> policy [1]. While the exact implementation details are to be determined
> yet, please note that *Signed-off-by* line will mean you are certifying
> our GCO [2].
>
# Michał Górny (17 Sep 2018)
# Obsolete LogiLab packages that are full of issues and were never
# maintained properly. Recently dev-python/logilab-common started
# colliding with dev-python/pytest, making it practically non-
# installable. The only revdep left is app-vim/python-mode where
# the
On 9/17/18 at 5:24 PM user Matt Turner wrote:
> I don't understand what a potential solution would be.
>
> The various projects use -std=c++XXX because that's what their code
> requires. -std=c++XXX can't generally be changed. If a dependent
> project is incompatible that's no different than any o
On Mon, Sep 17, 2018 at 04:00:26PM +0200, Guilherme Amadio wrote:
> Hi everyone,
>
> We have several packages (~35) with local USE=cuda. Should we make that
> a global USE flag? It's a quite generic flag for GPU support, so I was
> surprised to learn it was still local when I added support for it
I don't understand what a potential solution would be.
The various projects use -std=c++XXX because that's what their code
requires. -std=c++XXX can't generally be changed. If a dependent
project is incompatible that's no different than any other case of
incompatible dependencies in Gentoo.
I thi
I'd prefer to wait another replies on the list for the main theme of this e-
mail, but this problem also affects C (so, as **c**flags and C standards), so
solution shoudn't be c++ specific, imho.
Hi everyone,
I would like to discuss a system-wide way to handle C++ standard setting
in Gentoo. We currently have many packages appending -std=c++XX to their
flags, and it's hard to keep track of which packages use which version
of the standard. This is a problem when packages force dependencies
Hi everyone,
We have several packages (~35) with local USE=cuda. Should we make that
a global USE flag? It's a quite generic flag for GPU support, so I was
surprised to learn it was still local when I added support for it to a
package recently.
Another thing we might want to discuss is a global s
13 matches
Mail list logo
