Hi, Am Samstag, dem 23.07.2022 um 23:41 +0200 schrieb Maxime Devos: > > However, that's was I was trying to say -- what I tried to say, is > that by sorting the inputs incorrectly it _becomes_ not > cross-compilable, so once daikichi supports cross-compilation you > (generic you, not you in particular) will have to modify the package > to move daikichi to native-inputs, and in the mean time people are > misled by this package definition on how native / non-native works. Fair enough, I'll include it in the native-inputs.
> Even better would be if daikichi had a cross-compiler mode, where you > can compile to another endianness or size. (Or simpler, work with a > fixed endianness and integer size such that cross-compilation > concerns disappear entirely, but there's more than one way to do it.) We're speaking of a hack job done in a few evenings here, but I think a cross-compiler mode will be more feasible than fixed sizes (assuming that we won't cross-compile to larger integer sizes than supported by the host, which I think is a fair assumption to make). > Another problem is that currently it is propagated, but daikichi is > not a dependency of fortunes-jkirchartz. Well, it is a dependency in that you need a fortune program to read the quotes. Should I instead add a meta-package that propagates both?
