Linux Media Controller development
 help / color / mirror / Atom feed
From: Gregor Jasny <gjasny@googlemail.com>
To: Ariel D'Alessandro <ariel@vanguardiasur.com.ar>,
	Xavier Claessens <xavier.claessens@collabora.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Ezequiel Garcia <ezequiel@collabora.com>
Cc: kieran.bingham@ideasonboard.com, linux-media@vger.kernel.org,
	hverkuil@xs4all.nl, sean@mess.org, p.zabel@pengutronix.de,
	nicolas@ndufresne.ca,
	nicolas Dufresne <nicolas.dufresne@collabora.com>
Subject: Re: [PATCH v1 1/1] Add support for meson building
Date: Wed, 24 Jun 2020 21:46:28 +0200	[thread overview]
Message-ID: <4d8eecf2-3ce5-927b-bb3d-d950d123f0e0@googlemail.com> (raw)
In-Reply-To: <1586973f-5f69-fed0-4ad8-266cdd8e818b@vanguardiasur.com.ar>

Hello,

thanks for your helpful suggestions. I made a PR from those: Feel free 
to squash it into yours:
https://gitlab.com/adalessandro/v4l-utils/-/merge_requests/1

When looking at your quoted code with the fixes I'm wondering if you 
forgot to push your branch?

On 6/23/20 7:26 PM, Ariel D'Alessandro wrote:
> On 6/22/20 4:09 PM, Gregor Jasny wrote:
>> I noticed the following:
>> * library symlinks are not in place
>>    see https://packages.debian.org/sid/amd64/libv4l-0/filelist
> 
> Right. Each library target should have soversion and version set in order to
> create the proper symlinks. As follows:
>
> 
> BTW, shall we set these fields in meson with the proper version tag?

I don't think so because v4l-utils feels more like a mono-repo. Each 
library is versioned independently.

I have some more comments:
* The project version is still at 1.19.0 (should be 1.21.0 for the merge)

* As long as we support autotools and use 'make dist' to create the 
tarball we'd have to add the meson.build and meson_options.txt to the 
EXTRA_DIST of the respective Makefile.am.

* for ir-keytable the following variables are set and forwarded to the 
source code as a preprocessor define:

ir_keytable_system_dir = udevdir
ir_keytable_user_dir = get_option('sysconfdir') / 'rc_keymaps'

It would be nice if we could re-use those as the install-dir base here:
udevdir / 'rc_keymaps'

(But that's nice to have)

* Right now on install we create an empty directory at the 
ir_keytable_user_dir. Are you aware of any mechanism to create this with 
meson? I found https://github.com/mesonbuild/meson/issues/2904 and it 
makes me think that there is no easy way to do so. I could imaging to 
work-around by putting a readme file inside of that directory to have it 
created. That would also explain its reason for existence.

I'm still very fascinated of the very high build speed improvement. For 
me it's down to 8s (with cold cache). Very impressive. Thank you, again!

Thanks,
Gregor

  reply	other threads:[~2020-06-24 19:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-18 13:33 [PATCH v1 0/1] Add support for meson building Ariel D'Alessandro
2020-06-18 13:33 ` [PATCH v1 1/1] " Ariel D'Alessandro
2020-06-18 13:57   ` Kieran Bingham
2020-06-18 14:06     ` Laurent Pinchart
2020-06-18 14:11       ` Kieran Bingham
2020-06-19 14:12     ` Ezequiel Garcia
2020-06-19 14:42       ` Laurent Pinchart
2020-06-19 18:40         ` Xavier Claessens
2020-06-20  4:45           ` VDRU VDRU
2020-06-22 18:07           ` Gregor Jasny
2020-06-22 19:09             ` Gregor Jasny
2020-06-23 17:26               ` Ariel D'Alessandro
2020-06-24 19:46                 ` Gregor Jasny [this message]
2020-06-25 18:32                   ` Ariel D'Alessandro
2020-06-29 18:44                     ` Gregor Jasny
2020-07-03  2:15                       ` Ariel D'Alessandro
2020-06-25 18:52                 ` Ariel D'Alessandro
2020-06-29 18:56                   ` Gregor Jasny
2020-07-08  5:48                     ` Ariel D'Alessandro
2020-07-16 19:48                       ` Gregor Jasny
2020-06-19 19:04       ` Xavier Claessens
2020-06-22 19:19     ` Ariel D'Alessandro
2020-06-19 12:10 ` [PATCH v1 0/1] " Sean Young
2020-06-19 14:09   ` Ezequiel Garcia

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=4d8eecf2-3ce5-927b-bb3d-d950d123f0e0@googlemail.com \
    --to=gjasny@googlemail.com \
    --cc=ariel@vanguardiasur.com.ar \
    --cc=ezequiel@collabora.com \
    --cc=hverkuil@xs4all.nl \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=nicolas.dufresne@collabora.com \
    --cc=nicolas@ndufresne.ca \
    --cc=p.zabel@pengutronix.de \
    --cc=sean@mess.org \
    --cc=xavier.claessens@collabora.com \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox