From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] package/uftrace: new package
Date: Sun, 4 Apr 2021 11:03:38 +0200 [thread overview]
Message-ID: <20210404090338.GD2252@scaer> (raw)
In-Reply-To: <20210403191609.1168606-1-asafka7@gmail.com>
Asaf, All,
On 2021-04-03 22:16 +0300, Asaf Kahlon spake thusly:
> The uftrace tool is to trace and analyze execution of a
> program written in C/C++. It was heavily inspired by the
> ftrace framework of the Linux kernel (especially function
> graph tracer) and supports userspace programs.
> It supports various kind of commands and filters to help
> analysis of the program execution and performance.
Rather than duplicate the package description in the commit log, I
think it makes more sense that it contains explanations about the
packaging in Buildroot. See below.
> Signed-off-by: Asaf Kahlon <asafka7@gmail.com>
> ---
> DEVELOPERS | 1 +
> package/Config.in | 1 +
> package/busybox/busybox. | 0
Uh? ;-)
[--SNIP--]
> diff --git a/package/uftrace/Config.in b/package/uftrace/Config.in
> new file mode 100644
> index 0000000000..ca3041195e
> --- /dev/null
> +++ b/package/uftrace/Config.in
> @@ -0,0 +1,12 @@
> +config BR2_PACKAGE_UFTRACE
> + bool "uftrace"
> + depends on BR2_arm || BR2_aarch64 || BR2_x86_64
AFAICS, it also support i386...
Even though the architecture dependencies are pretty trivial today, I
think it would be good to introduce a _ARCH_SUPPORTS symbol:
config BR2_PACKAGE_UFTRACE_ARCH_SUPPORTS
bool
default y if BR2_arm
default y if BR2_aarch64
default y if BR2_i386
default y if BR2_x86_64
config BR2_PACKAGE_UFTRACE
bool "uftrace"
depends on BR2_PACKAGE_UFTRACE_ARCH_SUPPORTS
[--SNIP--]
> diff --git a/package/uftrace/uftrace.mk b/package/uftrace/uftrace.mk
> new file mode 100644
> index 0000000000..b696ac4c6e
> --- /dev/null
> +++ b/package/uftrace/uftrace.mk
> @@ -0,0 +1,26 @@
> +################################################################################
> +#
> +# uftrace
> +#
> +################################################################################
> +
> +UFTRACE_VERSION = 0.9.4
> +UFTRACE_SITE = https://github.com/namhyung/uftrace/archive/refs/tags
Please use the github macro; see e.g. boot/shim/shim.mk and the manual:
https://buildroot.org/downloads/manual/manual.html#github-download-url
> +UFTRACE_SOURCE = v0.9.4.tar.gz
No need to specify _SOURCE when using the github macro.
> +UFTRACE_LICENSE = GPL-2.0
> +UFTRACE_LICENSE_FILES = COPYING
> +
> +ifeq ($(BR2_PACKAGE_ELFUTILS),y)
> +UFTRACE_DEPENDENCIES += elfutils
> +endif
> +
> +define UFTRACE_BUILD_CMDS
> + $(TARGET_CONFIGURE_OPTS) ARCH=$(BR2_ARCH) $(MAKE) -C $(@D) $(UFTRACE_MAKE_OPTS)
You are not setting UFTRACE_MAKE_OPTS anywhere that I can see...
> +endef
>
> +define UFTRACE_INSTALL_TARGET_CMDS
> + $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D) DESTDIR=$(TARGET_DIR) \
> + $(UFTRACE_MAKE_OPTS) install
> +endef
> +
> +$(eval $(generic-package))
There is a ./configure script (but it is not autotools, so this truly is
a generic-package indeed): any reason why you are not using it? A little
note about it in the commit log would be nice.
I was wondering if having a host variant would not be interesting too.
Indeed, uftrace has a record mode, where it has a 'record' mode where it
stores all the traces into a file, and replay/report/graph modes where
it reads from that file to do off-sire analysis. So one might be
interested in running in record mode in the target, and doing the
analysis on the development machine...
Thoughts?
Regards,
Yann E. MORIN.
> --
> 2.27.0
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2021-04-04 9:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-03 19:16 [Buildroot] [PATCH 1/1] package/uftrace: new package Asaf Kahlon
2021-04-04 9:03 ` Yann E. MORIN [this message]
2021-04-04 10:07 ` Thomas Petazzoni
2021-04-08 18:45 ` Asaf Kahlon
2021-04-08 18:52 ` Asaf Kahlon
-- strict thread matches above, loose matches on Subject: below --
2020-10-26 23:14 Giacomo Longo
2020-10-27 9:36 ` Thomas Petazzoni
2020-10-27 15:14 ` Giacomo Longo
2020-11-03 20:39 ` Thomas Petazzoni
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=20210404090338.GD2252@scaer \
--to=yann.morin.1998@free.fr \
--cc=buildroot@busybox.net \
/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