[oe] [meta-oe][PATCH 1/7] linuxptp: Create 1.4 version

[Denys Dmytriyenko]

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 at 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 at 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