Openembedded Core Discussions
 help / color / mirror / Atom feed
From: "dengke.du@windriver.com" <dengke.du@windriver.com>
To: Randy MacLeod <randy.macleod@windriver.com>,
	<openembedded-core@lists.openembedded.org>,
	"Burton, Ross" <ross.burton@intel.com>
Subject: Re: [PATCH 0/2] perf: enable man pages for 'help' functionality
Date: Thu, 4 Aug 2016 09:35:22 +0800	[thread overview]
Message-ID: <57A29BDA.7040807@windriver.com> (raw)
In-Reply-To: <77e5544f-6c2a-93ea-3764-dbbdab150528@windriver.com>

Hi Randy & Ross

1. After my test, python2 & python3 works well.
2. I will follow-up the packages docs related to the asciidoc and work 
on the
     generation of docs, let it be optional.

//dengke

On 2016年08月03日 01:59, Randy MacLeod wrote:
>
> As Ross asked in a separate reply, we should discuss
> the pros and cons of making the host-based generation of docs
> be optional. I think that's the way to go since, in the common case
> of not enabling docs, the builds would be faster and the output smaller.
>
> On 2016-07-31 09:33 PM, dengke.du@windriver.com wrote:
>> Hi Randy
>>
>> 1.  I have checked the asciidoc-native: 3.1M
>>
>> 2.  real    4m41.858s
>>      user    27m3.280s
>>      sys    6m32.372s
>
>
>
> Those numbers, on their own, are not useful.
>
> How long does it take to build another native package on your system?
> What's the overall time  and time difference to build an image without
> and then with asciidoc and perf (and maybe ccache, git, trace-cmd)
> docs being generated? Alternatively just make the generation of docs
> be optional and then the time isn't a critical concern.
>
> You should follow-up, ***later*** by enabling doc generation for:
>
> commit 40627f5c334544178b056078da5e1d645ebd2a38
> Author: Robert Yang <liezhi.yang@windriver.com>
> Date:   Mon Jul 25 01:16:31 2016 -0700
>
>     ccache: 3.2.4 -> 3.2.5
>
>     Add Revert-Create-man-page-in-the-make-install-from-git-.patch to
>     disable asciidoc since we don't have it.
>
>
> and perhaps:
>
>
> commit 9aba4bf2143c228d58aac06764f87ace5dd21d02
> Author: Paul Gortmaker <paul.gortmaker@windriver.com>
> Date:   Tue Feb 10 14:17:37 2015 -0500
>
>     git: expand recipe to take advantage of pre-gen'd manpages
>
>     These could be created from scratch from git itself, but it
>     requires asciidoc, xsltproc, python bits and too much other
>     baggage.  Since the git folks issue a tarball with the manpages
>     for each release, it is simpler to just go get that.
>
> and:
>
> commit 73ac48377491561151658617d8cc45936242eb0c
> Author: Darren Hart <dvhart@linux.intel.com>
> Date:   Wed Nov 30 17:58:52 2011 -0800
>
>     trace-cmd: Update to 1.2 (includes kernelshark)
>
>>
>> 3.  Yes, the build system using python3.
>
> so what about python2? Does asciidoc require a specific major version
> of python?
>
> ../Randy
>
>>
>> //dengke
>>
>> On 2016年07月28日 02:23, Randy MacLeod wrote:
>>> On 2016-07-27 01:02 AM, Dengke Du wrote:
>>>> The following changes since commit
>>>> 36feb38045b7a2af86ece147fec54b0db3bf491f:
>>>>
>>>>   linux-yocto: Update genericx86* SRCREVs for linux-yocto 4.4
>>>> (2016-07-21 07:48:53 +0100)
>>>>
>>>> are available in the git repository at:
>>>>
>>>>   git://git.openembedded.org/openembedded-core-contrib
>>>> dengke/enable-help-man-pages-for-perf
>>>> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=dengke/enable-help-man-pages-for-perf 
>>>>
>>>>
>>>>
>>>> Dengke Du (2):
>>>>   Asciidoc: add it
>>>>   perf: enable man pages for 'help' functionality
>>>>
>>>>  meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb | 20
>>>> ++++++++++++++++++++
>>>>  meta/recipes-kernel/perf/perf.bb                 | 11 ++++++++++-
>>>>  2 files changed, 30 insertions(+), 1 deletion(-)
>>>>  create mode 100644 meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
>>>>
>>>
>>> Looks good .
>>>
>>> I was under the impression that asciidoc was larger but it's just
>>>  ~ 900KB plus it's all python so it's not going to add to the system
>>> build time directly.
>>>
>>> How much longer does it take to build perf?
>>>
>>> Did you test for python3 only?
>>>
>>
>
>



      reply	other threads:[~2016-08-04  1:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-27  5:02 [PATCH 0/2] perf: enable man pages for 'help' functionality Dengke Du
2016-07-27  5:02 ` [PATCH 1/2] Asciidoc: add it Dengke Du
2016-07-27  5:02 ` [PATCH 2/2] perf: enable man pages for 'help' functionality Dengke Du
2016-08-02 16:56   ` Burton, Ross
2016-08-02 20:06     ` Joshua G Lock
2016-07-27 18:23 ` [PATCH 0/2] " Randy MacLeod
2016-08-01  1:33   ` dengke.du
2016-08-02 17:59     ` Randy MacLeod
2016-08-04  1:35       ` dengke.du [this message]

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=57A29BDA.7040807@windriver.com \
    --to=dengke.du@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=randy.macleod@windriver.com \
    --cc=ross.burton@intel.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