Ben de Groot: >>> >>> EAPI=5 >>> inherit toolchain-funcs >>> >> >> This breaks consistency. Now users cannot rely on games.eclass anymore. >> We should either abandon it completely or follow it consistently. > > I thought we had abandoned it already? > > Is there anything to be gained from using games.eclass here? It is a > chess engine that simply installs one file in /usr/bin/. >
Well, almost everything in games-engines/ uses games.eclass too. Just the stuff in dev-games/ doesn't, because it's well... development stuff. The idea behind games.eclass was to unify games installations in gentoo. That involves common directories like /usr/games/bin and also special permissions that were meant to aid administrators to restrict access to games. A lot of people have expressed that this doesn't look like the right way in some sense (including me). It has also caused some weird bug, e.g. for nethack. But, my point is... whatever we do, we should do it consistently, otherwise people might get the idea of not caring about abstractions like python-r1, ruby/java/perl eclasses or whatever, because they don't like them. The council just chose the worst way, because it didn't want to upset either party involved in the discussion. >>> SRC_URI="https://stockfish.s3.amazonaws.com/${P}-src.zip"; >>> >>> LICENSE="GPL-3" >>> SLOT="0" >>> KEYWORDS="~amd64 ~x86" >>> IUSE="cpu_flags_x86_avx2 cpu_flags_x86_popcnt cpu_flags_x86_sse" >>> >>> DEPEND="" >> >> unzip is missing from DEPEND > > I thought portage auto-depends on this. But I can add || ( unzip zip ) > to be explicit. > I don't know, but it's definitely not in @system. Afair we are only allowed to omit deps from that set. >>> src_compile() { >>> local my_arch >>> use x86 && my_arch=x86-32-old >>> use cpu_flags_x86_sse && my_arch=x86-32 >>> use amd64 && my_arch=x86-64 >>> use cpu_flags_x86_popcnt && my_arch=x86-64-modern >>> use cpu_flags_x86_avx2 && my_arch=x86-64-bmi2 >>> >>> emake build ARCH=${my_arch} CXX="$(tc-getCXX)" CXXFLAGS="${CXXFLAGS}" >> >> This currently breaks all cpu flags, because it overwrites anything the >> Makefile does to CXXFLAGS, including -msse and -DIS_64BIT and even other >> flags that are not CPU specific (e.g. -DNDEBUG). > > Thanks for catching this! I guess we do need to patch the Makefile > then, to *also* honour user-set CXXFLAGS and LDFLAGS. Or could we get > away with just letting the Makefile do its thing? > I've hit this bug myself in my overlay... I'll probably get up a pull request upstream today.
