Re: [gentoo-dev] [PATCH] games-strategy/wargus: Fix running it with games-engines/stratagus[debug]
On Thursday, 15 February 2024 at 16:09, Michał Górny wrote:
> On Thu, 2024-02-15 at 14:21 +0100, z...@gentoo.org wrote:
>
> > Am 15.02.24 um 13:59 schrieb Eli Schwartz:
> >
> > > On 2/15/24 7:53 AM, Matthias Schwarzott wrote:
> > >
> > > > When stratagus is compiled with USE=debug, its executable is called
> > > > /usr/bin/stratatgus-dbg.
> > > >
> > > > Signed-off-by: Matthias Schwarzott z...@gentoo.org
> > > > ---
> > > > games-strategy/wargus/wargus-3.3.2.ebuild | 6 --
> > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/games-strategy/wargus/wargus-3.3.2.ebuild
> > > > b/games-strategy/wargus/wargus-3.3.2.ebuild
> > > > index fff6023fa177..3295b2911d48 100644
> > > > --- a/games-strategy/wargus/wargus-3.3.2.ebuild
> > > > +++ b/games-strategy/wargus/wargus-3.3.2.ebuild
> > > > @@ -1,4 +1,4 @@
> > > > -# Copyright 1999-2022 Gentoo Authors
> > > > +# Copyright 1999-2024 Gentoo Authors
> > > > # Distributed under the terms of the GNU General Public License v2
> > > >
> > > > EAPI=8
> > > > @@ -46,10 +46,12 @@ pkg_pretend() {
> > > > }
> > > >
> > > > src_configure() {
> > > > + local suffix=
> > > > + has_version games-engines/stratagus[debug] && suffix=-dbg
> > > > local mycmakeargs=(
> > > > -DGAMEDIR="${EPREFIX}/usr/bin"
> > > > -DBINDIR="${EPREFIX}/usr/bin"
> > > > - -DSTRATAGUS="${EPREFIX}/usr/bin/stratagus"
> > > > + -DSTRATAGUS="${EPREFIX}/usr/bin/stratagus${suffix}"
> > > > -DSHAREDIR="${EPREFIX}/usr/share/stratagus/wargus"
> > > > -DICONDIR=/usr/share/icons/hicolor/64x64/apps
> > > > -DWITH_STORMLIB=$(usex bne)
> > >
> > > Ok so this just means the package will be broken if you change the USE
> > > flags for stratagus and wargus doesn't get rebuilt.
> >
> > Exactly. It would even be simpler to patch that renaming out. I will
> > send a change to stratagus-ebuild.
> >
> > > Why is the executable name different, anyway?
> >
> > I have no clue. My guess is to have a separate executable.
> >
> > This is from stratagus CMakeLists.txt:
> > cut ===
> > if(CMAKE_BUILD_TYPE STREQUAL "Debug")
> > set_target_properties(stratagus PROPERTIES OUTPUT_NAME stratagus-dbg)
> > endif()
> > cut ===
>
>
> Wait, why are we changing CMAKE_BUILD_TYPE in the first place?!
>
The debug use flag could be dropped altogether or at least replaced with
append-cppflags -DDEBUG instead of setting CMAKE_BUILD_TYPE. The only relevant
thing that setting CMAKE_BUILD_TYPE to Debug does is to add -DDEBUG to CPPFLAGS.
https://github.com/search?q=repo%3AWargus%2Fstratagus+%2F%23ifdef+DEBUG%2F=code
--
Alfred Wingate
Re: [gentoo-dev] How to add -std=c++14 to CXXFLAGS of a cmake.eclass based package?
Hi, > but this makes no difference, c++17 is still used. How to convince > cmake_src_compile to use -std=c++14? Cmake sets those flags during src_configure (when the build dir is configured) and therefore ignores CXXFLAGS entirely during src_compile. You should set those in src_configure before cmake_src_configure gets called. And Arsen Arsenovićs reply applies here on how to use flag-o-matic function append-cxxflags to do it. -- Alfred Wingate
Re: [gentoo-dev] setuptools problem
Hello,
You should add DISTUTILS_USE_PEP517=hatchling.
A good resource for python ebuilds is here
https://projects.gentoo.org/python/guide/distutils.html?highlight=pep517#the-pep-517-and-legacy-modes
--- Original Message ---
On Monday, October 10th, 2022 at 11:08, Andrey Grozin
wrote:
> Hello *,
>
> I'm trying to bump dev-python/rpyc to 5.2.3, and I get
>
> > > > Compiling source in
>
> /var/tmp/portage/dev-python/rpyc-5.2.3/work/rpyc-5.2.3 ...
> * python3_9: running distutils-r1_run_phase distutils-r1_python_compile
> python3.9 -c from setuptools import setup; setup() build -j 6
> configuration error: `project.license` must be valid exactly by one
> definition (2 matches found):
>
> - keys:
> 'file': {type: string}
> required: ['file']
> - keys:
> 'text': {type: string}
> required: ['text']
>
> DESCRIPTION:
> `Project license `_.
>
>
> GIVEN VALUE:
> "MIT"
>
> OFFENDING RULE: 'oneOf'
>
> DEFINITION:
> {
> "oneOf": [
> {
> "properties": {
> "file": {
> "type": "string",
> "$$description": [
> "Relative path to the file (UTF-8) which
> contains the license for the",
> "project."
> ]
> }
> },
> "required": [
> "file"
> ]
> },
> {
> "properties": {
> "text": {
> "type": "string",
> "$$description": [
> "The license of the project whose meaning is
> that of the",
> "`License field from the core metadata",
> "`_."
>
> ]
> }
> },
> "required": [
> "text"
> ]
> }
> ]
> }
> Traceback (most recent call last):
> File "", line 1, in
>
> File "/usr/lib/python3.9/site-packages/setuptools/init.py", line 87,
> in setup
> return distutils.core.setup(**attrs)
> File "/usr/lib/python3.9/distutils/core.py", line 121, in setup
> dist.parse_config_files()
> File "/usr/lib/python3.9/site-packages/setuptools/dist.py", line 868, in
> parse_config_files
> pyprojecttoml.apply_configuration(self, filename,
> ignore_option_errors)
> File
> "/usr/lib/python3.9/site-packages/setuptools/config/pyprojecttoml.py",
> line 62, in apply_configuration
> config = read_configuration(filepath, True, ignore_option_errors,
> dist)
> File
> "/usr/lib/python3.9/site-packages/setuptools/config/pyprojecttoml.py",
> line 126, in read_configuration
> validate(subset, filepath)
> File
> "/usr/lib/python3.9/site-packages/setuptools/config/pyprojecttoml.py",
> line 51, in validate
> raise ValueError(f"{error}\n{summary}") from None
> ValueError: invalid pyproject.toml config: `project.license`.
> configuration error: `project.license` must be valid exactly by one
> definition (2 matches found):
>
> - keys:
> 'file': {type: string}
> required: ['file']
> - keys:
> 'text': {type: string}
> required: ['text']
>
> Any idea what has gone wrong? By googling I've found
> https://github.com/vanheeringen-lab/seq2science/issues/851
> https://bytemeta.vip/repo/jdtuck/fdasrsf_python/issues/23
> which seem similar.
>
> Thanks in advance,
> Andrey
