[bug#58100] [PATCH] gnu: cbqn: factor out singeli into derivative package.

[Christopher Rodriguez]

Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> writes:

> This is not how to write a ChangeLog.  See [1] or infer from other
> commits.

Thank You for pointing me in the right direction; I will ensure a
standardized changelog in my revised patch after reading all of the
linked info.

>> -         (commit "9c1cbdc99863b1da0116df61cd832137b196dc5c"))
>> +         (commit "bd823839feaf42af4013e5a245981f58f563e659"))
> Why are you changing the bootstrap commit?  This looks suspicious.

I am bumping the commit from 9c1cbdc99863b1da0116df61cd832137b196dc5c to
46501ac819c8f21c69d7d2ba4b0457a7356f5e42 (another commit was made when
closing the above-linked issue) as the new commit is the most recent one
for this un-tagged project.

There is no 'release' to package, and so in order to stay up to date
regular updates of this package's commit will likely be necessary.

I can see why the bootstrap commit might stay the same, however. Would
it be better to solely amend the commit on the actual installable
package instead?

>>      (arguments
>> -     (list #:make-flags '(list "shared-o3" "o3n-singeli")
>> +     (list #:make-flags '(list "shared-o3" "o3")
> Okay

I have actually just re-read the documentation after the abovementioned
most recent commit, and noticed a surviving line in the upstream
`README.md`[1]:

`make PIE=""` on ARM CPUs (incl. Android & M1)

Perhaps I can incorporate this into the package to allow it to build on
aarch64 as well as x86_64? Though as mentioned in the original upstream
issue, I think there is a problem with a dependent package… perhaps this
should be saved for a separate issue, then.

> Instead of providing a singeli variant, would just tuning the package
> suffice?
This was actually my biggest question when making the patch. I chose a
singeli variant because there is no architecture detection at all in the
makefile; it relies entirely on the specified targets ("o3", "c", etc)
to decide what to build for.

As an example: Switching the target from "o3n-singeli" to "o3"
immediately changed the entire build, preventing it from looking at all
for Singeli sources, even though I had yet to unlink them from the
source directory.

Is there a preferred method for this kind of build structure in a Guix
package? I suppose I could do a (cond *) in the make flags… maybe
referencing a variable for the target? I don't know what variable that
might be, though, as we would not only be looking for an x86_64 target,
but specifically that the underlying system supports AVX2…

In general, I would much prefer to keep it as one package. I think it is
much easier to maintain that way, and makes the user experience much
easier as well. But I'm sorry to report that I'm unaware of how best to
implement this, and would greatly appreciate some advice.

> If not, I think we should try to properly unbundle singeli (as in
> build an actual singeli package) before adding another package
> variant.  Then, you could use existing patterns to decide whether to
> use singeli by making it an input or not.

As for unbundling singeli: Running singeli requires a version of cbqn
built with or without singeli support. Building a version of cbqn with
singeli support requires the /source/ for singeli to be present in the
build directory at build time, not a precompiled binary. Singeli itself
is actually just a BQN script[2], and not a compiled binary at all, and
is a transpiler from BQN to IR/C. It's used in the optimized version to
transpile/compile the SIMD algorithms (sic, I am unfamiliar with this
concept).

In short, to unbundle singeli, we can just avoid including singeli in
the build, as in the revised cbqn package in the patch. We could make a
package for singeli that uses an installed bqn binary from any cbqn
package, but we would still need the sources present at build time due
to the way they are used and called in the build script. Fully
decoupling the optimized cbqn from singeli would require rewriting the
parts of the build that locate and run the singeli script, and (I think)
is more suited to an upstream patch than a package definition. I have
opened an issue regarding this possibility with upstream as of this
email[3].

(FWIW, I've also opened an issue regarding release tagging[4], though
from my previous correspondence with upstream I'm fairly certain a
release tag is not yet something they are comfortable with).

>
> Cheers

Thank You (as always) for Your guidance, Liliana. Sorry for these
issues, I am still learning best practices and standards for this
project and those of GNU in general. I hope You have a great day!

[1]: 
https://github.com/dzaima/CBQN/commit/46501ac819c8f21c69d7d2ba4b0457a7356f5e42
[2]: https://github.com/mlochbaum/Singeli/blob/master/singeli
[3]: https://github.com/dzaima/CBQN/issues/46
[4]: https://github.com/dzaima/CBQN/issues/47

-- 
Christopher Rodriguez
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

signature.asc
Description: PGP signature