| 1 |
Ben de Groot: |
| 2 |
>>> |
| 3 |
>>> EAPI=5 |
| 4 |
>>> inherit toolchain-funcs |
| 5 |
>>> |
| 6 |
>> |
| 7 |
>> This breaks consistency. Now users cannot rely on games.eclass anymore. |
| 8 |
>> We should either abandon it completely or follow it consistently. |
| 9 |
> |
| 10 |
> I thought we had abandoned it already? |
| 11 |
> |
| 12 |
> Is there anything to be gained from using games.eclass here? It is a |
| 13 |
> chess engine that simply installs one file in /usr/bin/. |
| 14 |
> |
| 15 |
|
| 16 |
Well, almost everything in games-engines/ uses games.eclass too. Just |
| 17 |
the stuff in dev-games/ doesn't, because it's well... development stuff. |
| 18 |
|
| 19 |
The idea behind games.eclass was to unify games installations in gentoo. |
| 20 |
That involves common directories like /usr/games/bin and also special |
| 21 |
permissions that were meant to aid administrators to restrict access to |
| 22 |
games. |
| 23 |
|
| 24 |
A lot of people have expressed that this doesn't look like the right way |
| 25 |
in some sense (including me). It has also caused some weird bug, e.g. |
| 26 |
for nethack. |
| 27 |
|
| 28 |
But, my point is... whatever we do, we should do it consistently, |
| 29 |
otherwise people might get the idea of not caring about abstractions |
| 30 |
like python-r1, ruby/java/perl eclasses or whatever, because they don't |
| 31 |
like them. |
| 32 |
|
| 33 |
The council just chose the worst way, because it didn't want to upset |
| 34 |
either party involved in the discussion. |
| 35 |
|
| 36 |
>>> SRC_URI="https://stockfish.s3.amazonaws.com/${P}-src.zip" |
| 37 |
>>> |
| 38 |
>>> LICENSE="GPL-3" |
| 39 |
>>> SLOT="0" |
| 40 |
>>> KEYWORDS="~amd64 ~x86" |
| 41 |
>>> IUSE="cpu_flags_x86_avx2 cpu_flags_x86_popcnt cpu_flags_x86_sse" |
| 42 |
>>> |
| 43 |
>>> DEPEND="" |
| 44 |
>> |
| 45 |
>> unzip is missing from DEPEND |
| 46 |
> |
| 47 |
> I thought portage auto-depends on this. But I can add || ( unzip zip ) |
| 48 |
> to be explicit. |
| 49 |
> |
| 50 |
|
| 51 |
I don't know, but it's definitely not in @system. Afair we are only |
| 52 |
allowed to omit deps from that set. |
| 53 |
|
| 54 |
>>> src_compile() { |
| 55 |
>>> local my_arch |
| 56 |
>>> use x86 && my_arch=x86-32-old |
| 57 |
>>> use cpu_flags_x86_sse && my_arch=x86-32 |
| 58 |
>>> use amd64 && my_arch=x86-64 |
| 59 |
>>> use cpu_flags_x86_popcnt && my_arch=x86-64-modern |
| 60 |
>>> use cpu_flags_x86_avx2 && my_arch=x86-64-bmi2 |
| 61 |
>>> |
| 62 |
>>> emake build ARCH=${my_arch} CXX="$(tc-getCXX)" CXXFLAGS="${CXXFLAGS}" |
| 63 |
>> |
| 64 |
>> This currently breaks all cpu flags, because it overwrites anything the |
| 65 |
>> Makefile does to CXXFLAGS, including -msse and -DIS_64BIT and even other |
| 66 |
>> flags that are not CPU specific (e.g. -DNDEBUG). |
| 67 |
> |
| 68 |
> Thanks for catching this! I guess we do need to patch the Makefile |
| 69 |
> then, to *also* honour user-set CXXFLAGS and LDFLAGS. Or could we get |
| 70 |
> away with just letting the Makefile do its thing? |
| 71 |
> |
| 72 |
|
| 73 |
I've hit this bug myself in my overlay... I'll probably get up a pull |
| 74 |
request upstream today. |
Archives