[bug#41574] gnu: Add intel-xev.

[Marius Bakke <marius@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 3517 bytes --]

elaexuotee@wilsonb.com writes:

> Marius,
>
> Thanks for taking a look at this.
>
>> Were these two downgrades intended?  I'm assuming no, since the new
>> package don't appear to use them.
>
> Definitely not. Looks like I was sloppy with a local rebase. Thanks for
> catching this.

OK.

>> Does it work to use 'python-wrapper' instead of providing both Python 2
>> and Python 3 here?
>
> Beautiful; 'python-wrapper' is exactly what I was looking for.

Great.

>> Is the src output used for other things than documentation?  If not, I
>> think we can drop it and let users do 'guix build --source intel-xed'
>> instead.  The description should be modified accordingly.
>
> Sounds emminently reasonable to me.

The new patch still has a "src" output, even though it does not seem to
use it.

>> Apart from this the package LGTM.  Probably it should have:
>> 
>>   (supported-systems '("x86_64-linux" "i686-linux"))
>> 
>> too?
>
> I'm not so sure, actually. The tool and library simply facilitate translating
> to/from x86 opcodes, but as far as I can tell it doesn't actually *execute* any
> architecture-specific instructions.

OK.

>> Can you add a short description at the top of the patch file explaining
>> what it does any why?
>
> Oh, neat. I didn't know this was possible.

Nice job on the comment.  :-)

>> Can you send an updated patch?  Thanks!
>
> Done!

Looks like I missed a couple of things in the first round, sorry about
that.  Here it comes...

> From a90ef5e79d863201d990d607c2926400654bfd9b Mon Sep 17 00:00:00 2001
> From: "B. Wilson" <elaexuotee@wilsonb.com>
> Date: Thu, 28 May 2020 07:32:28 +0900
> Subject: [PATCH] gnu: Add intel-xed.
> To: guix-patches@gnu.org
>
> * gnu/packages/assembly.scm (intel-xed): New variable.

Please also mention the new patch and change to local.mk in the commit
message.

[...]

> +(define-public intel-xed
> +  (package
> +    (name "intel-xed")
> +    (version "11.2.0")
> +    (source
> +     (origin
> +       (method git-fetch)
> +       (uri (git-reference
> +             (url "https://github.com/intelxed/xed.git")
> +             (commit "40125558530137444b4ee6fd26b445bfa105b543")))

Use the "11.2.0" tag here instead of the commit hash.

> +       (sha256 (base32 "1jffayski2gpd54vaska7fmiwnnia8v3cka4nfyzjgl8xsky9v2s"))
> +       (file-name (git-file-name name version))
> +       (patches (search-patches "intel-xed-fix-nondeterminism.patch"))))
> +    (build-system gnu-build-system)
> +    (native-inputs
> +     `(("python-wrapper" ,python-wrapper)
> +       ("tcsh" ,tcsh)
> +       ("mbuild"
> +        ,(let ((name "mbuild")
> +               (version "0.2496"))
> +           (origin
> +             (method git-fetch)
> +             (uri (git-reference
> +                   (url "https://github.com/intelxed/mbuild.git")
> +                   (commit "5304b94361fccd830c0e2417535a866b79c1c297")))
> +             (sha256
> +              (base32
> +               "0r3avc3035aklqxcnc14rlmmwpj3jp09vbcbwynhvvmcp8srl7dl"))
> +             (file-name (git-file-name name version)))))))

Can you add a comment about where you got that version number from?
Also, would it make sense to package this separately?  Can be done later
though.

> +    (outputs '("out" "lib" "src"))

As mentioned before, the 'src' output can go.

Apart from these minor issues, I think it's good to go.  \o/

Can you send an updated patch?  TIA!  :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]