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.

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.


>> +              (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...


>> +    (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?


live well,
  vagrant