[bug#63435] Add vcmi 1.2.1 to games.scm

[Liliana Marie Prikler]

Am Donnerstag, dem 11.05.2023 um 23:17 -0700 schrieb Vagrant Cascadian:
> On 2023-05-12, Liliana Marie Prikler wrote:
> > Am Donnerstag, dem 11.05.2023 um 16:07 -0700 schrieb Vagrant
> > Cascadian:
> > 
> > > +(define-public vcmi
> > > +  (package
> > > +    (name "vcmi")
> > > +    (version "1.2.1")
> > > +    (source (origin
> > > +              (method git-fetch)
> > > +              (uri (git-reference
> > > +                    (url "https://github.com/vcmi/vcmi";)
> > > +                    (commit version)
> > > +                    (recursive? #t)))
> > Can we do without the recursive checkout?
> 
> There is one component still used with the recursive
> checkout. ... AI/Fuzzy* I think? I do not know if it could be built
> independently, but I have not seriously looked into it.
fuzzylite can be taken from the system which is the preferred approach.

> 
> If tests were enabled, the googletest stuff might be needed; it was a
> bit unclear to me if the googletest packaged in guix could
> work. Regardless, tests are disabled upstream... so if there is a way
> to only download one and not the other, I guess that would save some
> bandwith.
> 
> I *think* those are the only two things pulled in.
Not that it matters if we aren't building tests, but googletest can and
should be unbundled.  There's a fair number of packages already setting
a precedent.

> > > +              (file-name (git-file-name name version))
> > > +              (sha256
> > > +               (base32
> > > +               
> > > "1nx3i078cxkak2ci514pf4pgi5269mp08njynsg35pin4yp3fn0p"))
> > > +              (patches (search-patches "vcmi-disable-privacy-
> > > breach.patch"))))
> > IIRC the reproducible builds patch is still missing, right?
> 
> The Debian package implements building man pages and documentation
> outside of the upstream build system...
> 
> It did not seem worth patching something that was not used to build
> anything... the reproducible builds patch(es) only apply to
> documentation which is not part of the upstream build process, so I
> left it out of this iteration.
> 
> That said...
> 
> Building vcmimanual.tex appears to be a one-liner, pulling in some
> tex related dependencies:
> 
>  
> https://salsa.debian.org/games-team/vcmi/-/blob/master/debian/rules#L56
> 
> And generating manpages used help2man and some templates debian
> ships:
> 
>  
> https://salsa.debian.org/games-team/vcmi/-/blob/master/debian/rules#L46-48
> 
> Not sure if the manpages are worth the effort, or if the manual is
> worth the larger dependency tree...
Fair enough, if it can be left without, let's do without (unless you
really want to build the manpage).  Alternatively, you can pull the
inputs in, but phrase the (build-documentation ...) phase in a way that
those inputs can be dropped if someone values their disk space.

> > > +    (native-inputs (list boost
> > Guix style is, like, a suggestion that can be wrong.  You are
> > allowed
> > to fight it when the result of doing so is demonstrably better.
> 
> I get that ... but I also like just being able to run guix style and
> not having to make those judgement calls. Because other things guix
> style may change that are a good idea and it is really difficult to
> pick and choose which things to revert and which to keep over time...
> 
> There are some things I think guix style does wrong(in particular, I
> always prefer one input per line to make diffs easier to read), but I
> do not hold strong opinions on guile coding style and just prefer to
> concede to guix style and bear with the results.
> 
> I am also not strongly opinionated (it goes both ways, I guess!)...
> so for clarity, are you saying you would prefer:
> 
>   (native-inputs
>     (list
>       boost
>       ...
> or:
> 
>   (native-inputs
>     (list boost
>           ...
> 
> or something else?
The latter.  If it ever comes to needing (list on its own line you
better have a good explanation for that or fix your comments so that
they don't go overboard.


Cheers