all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: "Björn Höfling" <bjoern.hoefling@bjoernhoefling.de>
Cc: 30801@debbugs.gnu.org
Subject: [bug#30801] [PATCH 0/1] Add opencv
Date: Thu, 15 Mar 2018 22:04:54 +0100	[thread overview]
Message-ID: <87po45rqx5.fsf@gnu.org> (raw)
In-Reply-To: <20180313175809.7d782c1a@alma-ubu> ("Björn Höfling"'s message of "Tue, 13 Mar 2018 17:58:09 +0100")

Hi Björn,

Björn Höfling <bjoern.hoefling@bjoernhoefling.de> skribis:

> The test suite consists of an extra package, weighting 465MB
> compressed. It runs very well. I think the size is worth it. It
> consists of proprietary things (i.e. lena.jpg). As far as I understand,
> that is OK, if it doesn't get in the final src/bin store output. Right?

As a rule of thumb, there should not be non-free stuff in the derivation
graph.

If there’s non-free software, that’s not OK, even if it doesn’t show up
in the output.

If it’s “just” data (pictures) that are non-free, that’s OK per the
FSDG:
<https://www.gnu.org/distros/free-system-distribution-guidelines.html#non-functional-data>.
If we could replace it with a free variant, I think we should clearly
encourage it, but lena.jpg is hardly replaceable in this context (I’d
hope it weren’t around for what it tells about CS, but that’s another
story…).

> CPU-optimization: I hope I have done everything right. Reading the
> article from Guix HPC a second time helped a lot. So now it should be
> compiled with SSE2/NEON being the minimum required instruction set, and
> dispatches to other ISAs where available.

Great.

> Size: Currently I load a bunch of dependencies in and have one
> big  package as output. guix size is 1.1 GiB. I slightly have the
> feeling someone could ask to split it in several outputs. Though having
> one big output was the easiest thing first and I don't know how one
> would handle inter-dependencies between the different outputs.

1.1G is a bit too much IMO, indeed.  :-)

How much is OpenCV itself?  If OpenCV itself is big, it would be nice to
look at what’s taking up space in there with ‘du’.  For instance, if
there are .a files, we might want to not build them and keep only shared
objects.

Splitting in separate outputs may or may not make sense.  If there are
examples or large pieces of HTML doc, introducing a “doc” and/or an
“examples” output may help.  Likewise, if there are binaries that depend
on more stuff that the library itself, introducing a “lib” output might
be a good idea.

Could you take a look?

Nitpick:

> +    (synopsis "Computer Vision Library")

No need to capitalize.

> +    (description "OpenCV (Open Source Computer Vision) is a library aimed at

I’d remove the parenthetic part.

> +real-time computer vision, including several hundred computer
> +vision algorithms.")

Bonus points if you can expound a little bit, without just listing those
algorithms though.  ;-)

Apart from that the patch looks very polished and that’s a pleasure to
review!

Thanks,
Ludo’.

  parent reply	other threads:[~2018-03-15 21:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-13 16:58 [bug#30801] [PATCH 0/1] Add opencv Björn Höfling
2018-03-13 17:07 ` [bug#30801] [PATCH 1/1] gnu: " Björn Höfling
2018-03-15 21:04 ` Ludovic Courtès [this message]
2018-03-31 22:26   ` [bug#30801] [PATCH 0/1] " Björn Höfling
2018-04-01 12:21     ` Ludovic Courtès
2018-05-07 18:35       ` [bug#30801] " Björn Höfling
2018-05-09 22:01         ` bug#30801: " Ludovic Courtès
2018-05-11  9:51           ` [bug#30801] " Björn Höfling
2018-05-11 12:00             ` Ludovic Courtès
2018-05-12 23:42               ` Björn Höfling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87po45rqx5.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=30801@debbugs.gnu.org \
    --cc=bjoern.hoefling@bjoernhoefling.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.