From: Denys Dmytriyenko <denis@denix.org>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [meta-oe][PATCH 1/7] linuxptp: Create 1.4 version
Date: Sat, 29 Mar 2014 17:08:03 -0400 [thread overview]
Message-ID: <20140329210803.GR3370@denix.org> (raw)
In-Reply-To: <CAP9ODKoM+pLGvXT6EkboDjSwcPhWqERCq86eznqZP5yvf1k7qg@mail.gmail.com>
On Sat, Mar 29, 2014 at 03:40:30PM -0300, Otavio Salvador wrote:
> Hello Denys,
>
> On Fri, Mar 28, 2014 at 3:00 PM, Denys Dmytriyenko <denis@denix.org> wrote:
> > On Fri, Mar 07, 2014 at 03:26:09PM -0600, Lauren Post wrote:
> >> Precision Time Protocol (PTP) according to IEEE standard 1588
> >
> > Heh, another instance of "duplication" - I also have a similar recipe in my
> > layer... Well, I do understand that "the early bird gets the worm" or the
> > first submitter gets his change merged, but let me point out few issues:
>
> This is the price of 'late upstreaming' :-(
Understood, see above :) There are many other factors involved, but we are
trying to improve in this regard...
> >> Signed-off-by: Lauren Post <lauren.post@freescale.com>
> >> ---
> >> .../recipes-connectivity/linuxptp/linuxptp_1.4.bb | 26 ++++++++++++++++++++
> >> 1 file changed, 26 insertions(+)
> >> create mode 100644 meta-oe/recipes-connectivity/linuxptp/linuxptp_1.4.bb
> >>
> >> diff --git a/meta-oe/recipes-connectivity/linuxptp/linuxptp_1.4.bb b/meta-oe/recipes-connectivity/linuxptp/linuxptp_1.4.bb
> >> new file mode 100644
> >> index 0000000..c708b13
> >> --- /dev/null
> >> +++ b/meta-oe/recipes-connectivity/linuxptp/linuxptp_1.4.bb
> >> @@ -0,0 +1,26 @@
> >> +DESCRIPTION = "Precision Time Protocol (PTP) according to IEEE standard 1588 for Linux"
> >> +LICENSE = "GPLv2"
> >> +LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> >> +
> >> +DEPENDS = "virtual/kernel"
> >> +
> >> +SRC_URI = "http://sourceforge.net/projects/linuxptp/files/v${PV}/linuxptp-${PV}.tgz"
> >> +
> >> +SRC_URI[md5sum] = "a37ad2b2ef7d1ebc4d64a66d3fe55cdf"
> >> +SRC_URI[sha256sum] = "6cfd5291fb7394cc9f25458927874a203971b66b76d1c9d6568e007d0cbd81f2"
> >> +
> >> +inherit autotools pkgconfig
> >
> > It's easy to see that linuxptp build doesn't really use autotools or pkgconfig
>
> What you suggest here?
Obviously, drop that line altogether :) There's nothing to inherit here.
> >> +EXTRA_OEMAKE = 'KBUILD_OUTPUT="${STAGING_KERNEL_DIR}" CROSS_COMPILE="${TARGET_PREFIX}"'
> >> +
> >> +do_configure_append () {
> >> + find ${S} -name makefile | xargs sed -i 's,^\(CC\|CFLAGS\|prefix\|AR\)=,\1 ?=,g'
> >
> > Why do you need to mangle the makefile? Passing CROSS_COMPILE and maybe ARCH
> > should be enough, isn't it?
>
> In fact I guess we do. Otherwise the build system won't use the build
> flags we expect, will it?
What about "prefix" then?
> >> +}
> >> +
> >> +do_install () {
> >> + install -d ${D}/${bindir}
> >> + install -p ${S}/ptp4l ${D}/${bindir}
> >> + install -p ${S}/pmc ${D}/${bindir}
> >> + install -p ${S}/phc2sys ${D}/${bindir}
> >> + install -p ${S}/hwstamp_ctl ${D}/${bindir}
> >> +}
> >
> > And the last bit about dependency on virtual/kernel above and passing
> > KBUILD_OUTPUT=STAGING_KERNEL_DIR to the build - I have looked into what that
> > does and it tries to locate the correct /usr/include/linux/net_tstamp.h just
> > to see if it contains definition for HWTSTAMP_TX_ONESTEP_SYNC. But that header
> > file hasn't changed in at least 5 years. Anyway, the result of the check is to
> > pass some defines to their build. I ended up just short-cutting the check and
> > avoid unnecessary dependency on virtual/kernel:
>
> Oh good hint here. This is indeed a nice boost in build and avoids
> rebuild when kernel changes.
>
> Could you share this change?
Sure, I can send a patch to address the above.
--
Denys
next prev parent reply other threads:[~2014-03-29 21:08 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <lauren.post@freescale.com>
2014-03-07 21:26 ` [meta-oe][PATCH 1/7] linuxptp: Create 1.4 version Lauren Post
2014-03-07 21:26 ` [meta-oe][PATCH 2/7] obexftp: Create 0.23 version Lauren Post
2014-03-07 21:26 ` [meta-oe][PATCH 3/7] can-utils: Create git version Lauren Post
2014-03-11 14:08 ` Martin Jansa
2014-03-11 14:26 ` Otavio Salvador
2014-03-07 21:26 ` [meta-oe][PATCH 4/7] glcompbench: Create 2012.08 version Lauren Post
2014-03-11 15:51 ` Martin Jansa
2014-03-07 21:26 ` [meta-oe][PATCH 5/7] gtkperf: Create 0.40 version Lauren Post
2014-03-11 14:14 ` Martin Jansa
2014-03-07 21:26 ` [meta-oe][PATCH 6/7] vlan: Create 1.9 version Lauren Post
2014-03-11 14:17 ` Martin Jansa
2014-03-17 16:26 ` Otavio Salvador
2014-03-17 17:24 ` Martin Jansa
2014-03-07 21:26 ` [meta-oe][PATCH 7/7] openobex: Remove --enable-dump to disable dumping Lauren Post
2014-03-28 18:00 ` [meta-oe][PATCH 1/7] linuxptp: Create 1.4 version Denys Dmytriyenko
2014-03-29 18:40 ` Otavio Salvador
2014-03-29 21:08 ` Denys Dmytriyenko [this message]
2014-06-27 17:13 ` [meta-oe][PATCH v3] cpuburn-neon: Upgrade to version 20140626 Lauren Post
2014-07-15 18:27 ` Otavio Salvador
2014-07-15 19:06 ` Martin Jansa
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=20140329210803.GR3370@denix.org \
--to=denis@denix.org \
--cc=openembedded-devel@lists.openembedded.org \
/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