Building hg/help2man not relying on them?

Building hg/help2man not relying on them?

[Tom Rini]

Hey all,

As I work on bringing jenkins up on my stripped down builder machines
I've once again run into the "wait, I'm supposed to have installed...?"
problem.  Can we switch to building help2man and mercurial rather than
making the end user install them?  Perhaps some sort of test for if we
find it, ASSUME_PROVIDED it, otherwise build it?

-- 
Tom Rini
Mentor Graphics Corporation

Re: Building hg/help2man not relying on them?

[Mark Hatle]

On 7/14/11 9:00 PM, Tom Rini wrote:
> Hey all,
> 
> As I work on bringing jenkins up on my stripped down builder machines
> I've once again run into the "wait, I'm supposed to have installed...?"
> problem.  Can we switch to building help2man and mercurial rather than
> making the end user install them?  Perhaps some sort of test for if we
> find it, ASSUME_PROVIDED it, otherwise build it?
> 

The full sanity list is:

patch help2man diffstat texi2html makeinfo cvs svn bzip2 tar gzip gawk hg
chrpath wget cpio

Of the above, help2man, texi2html, hg, and chrpath seem to be the ones I usually
have to find or build myself.

If we can build those (or setup the assume_provide) that would make it much
easier for me....

--Mark

Re: Building hg/help2man not relying on them?

[Joshua Lock]

On Thu, 2011-07-14 at 21:56 -0500, Mark Hatle wrote:
> On 7/14/11 9:00 PM, Tom Rini wrote:
> > Hey all,
> > 
> > As I work on bringing jenkins up on my stripped down builder machines
> > I've once again run into the "wait, I'm supposed to have installed...?"
> > problem.  Can we switch to building help2man and mercurial rather than
> > making the end user install them?  Perhaps some sort of test for if we
> > find it, ASSUME_PROVIDED it, otherwise build it?
> > 
> 
> The full sanity list is:
> 
> patch help2man diffstat texi2html makeinfo cvs svn bzip2 tar gzip gawk hg
> chrpath wget cpio
> 
> Of the above, help2man, texi2html, hg, and chrpath seem to be the ones I usually
> have to find or build myself.

Originally I built chrpath when I added relocatable.bbclass but then we
wanted to relocate native packages and it got extremely tricky...

Joshua
-- 
Joshua Lock
        Yocto Project "Johannes factotum"
        Intel Open Source Technology Centre

Re: Building hg/help2man not relying on them?

[Mark Hatle]

On 7/15/11 9:39 AM, Joshua Lock wrote:
> On Thu, 2011-07-14 at 21:56 -0500, Mark Hatle wrote:
>> On 7/14/11 9:00 PM, Tom Rini wrote:
>>> Hey all,
>>>
>>> As I work on bringing jenkins up on my stripped down builder machines
>>> I've once again run into the "wait, I'm supposed to have installed...?"
>>> problem.  Can we switch to building help2man and mercurial rather than
>>> making the end user install them?  Perhaps some sort of test for if we
>>> find it, ASSUME_PROVIDED it, otherwise build it?
>>>
>>
>> The full sanity list is:
>>
>> patch help2man diffstat texi2html makeinfo cvs svn bzip2 tar gzip gawk hg
>> chrpath wget cpio
>>
>> Of the above, help2man, texi2html, hg, and chrpath seem to be the ones I usually
>> have to find or build myself.
> 
> Originally I built chrpath when I added relocatable.bbclass but then we
> wanted to relocate native packages and it got extremely tricky...

I wonder if we can do something like pseudo and force chrpath to be built -very-
early in the process.. and then have most things have an automatic requirement
on chrpath-native...

(pseudo of course has the advantage it's NOT used for native packages...)

Is the native chrpath usage only in do_package [or later]?  If so, we could
probably put a dependency on do_package of chrpath.. with the affect that
chrpath would have to be built first...

--Mark

> 
> Joshua

Re: Building hg/help2man not relying on them?

[Tom Rini]

On 07/15/2011 07:43 AM, Mark Hatle wrote:
> On 7/15/11 9:39 AM, Joshua Lock wrote:
>> On Thu, 2011-07-14 at 21:56 -0500, Mark Hatle wrote:
>>> On 7/14/11 9:00 PM, Tom Rini wrote:
>>>> Hey all,
>>>>
>>>> As I work on bringing jenkins up on my stripped down builder machines
>>>> I've once again run into the "wait, I'm supposed to have installed...?"
>>>> problem.  Can we switch to building help2man and mercurial rather than
>>>> making the end user install them?  Perhaps some sort of test for if we
>>>> find it, ASSUME_PROVIDED it, otherwise build it?
>>>>
>>>
>>> The full sanity list is:
>>>
>>> patch help2man diffstat texi2html makeinfo cvs svn bzip2 tar gzip gawk hg
>>> chrpath wget cpio
>>>
>>> Of the above, help2man, texi2html, hg, and chrpath seem to be the ones I usually
>>> have to find or build myself.
>>
>> Originally I built chrpath when I added relocatable.bbclass but then we
>> wanted to relocate native packages and it got extremely tricky...
> 
> I wonder if we can do something like pseudo and force chrpath to be built -very-
> early in the process.. and then have most things have an automatic requirement
> on chrpath-native...
> 
> (pseudo of course has the advantage it's NOT used for native packages...)
> 
> Is the native chrpath usage only in do_package [or later]?  If so, we could
> probably put a dependency on do_package of chrpath.. with the affect that
> chrpath would have to be built first...

IIRC, it's somewhere between really tricky and just not possible to
nicely shove chrpath-native as a dependency into the graph.  I'm going
to pause my siteinfo stuff shortly and take a stab at mercurial and
help2man since I know the recipes exist in oe.dev and this time around
I'll take a stab at adding stuff to ASSUME_PROVIDED if found (oe.dev
just has help2man-native in local.conf.sample).

-- 
Tom Rini
Mentor Graphics Corporation

Re: Building hg/help2man not relying on them?

[Phil Blundell]

On Fri, 2011-07-15 at 08:08 -0700, Tom Rini wrote:
> IIRC, it's somewhere between really tricky and just not possible to
> nicely shove chrpath-native as a dependency into the graph. 

What's the difficulty with that?  Assuming that we're talking about
changing rpaths in the sysroot, obviously it wouldn't work for anything
that gets staged before chrpath (i.e. any of its own dependencies) but
apart from that I can't think of any obvious reason why it couldn't be
done.  Luckily chrpath doesn't depend on anything very much, just the
usual autotools stack, so it doesn't seem like there are very many
recipes that would have to be chrpath-inhibited.

(Of course, chrpath itself has quite a high suckage factor and maybe we
should get/make a better tool while we're worrying about this stuff.)

p.

Re: Building hg/help2man not relying on them?

[Richard Purdie]

On Fri, 2011-07-15 at 16:18 +0100, Phil Blundell wrote:
> On Fri, 2011-07-15 at 08:08 -0700, Tom Rini wrote:
> > IIRC, it's somewhere between really tricky and just not possible to
> > nicely shove chrpath-native as a dependency into the graph. 
> 
> What's the difficulty with that?  Assuming that we're talking about
> changing rpaths in the sysroot, obviously it wouldn't work for anything
> that gets staged before chrpath (i.e. any of its own dependencies) but
> apart from that I can't think of any obvious reason why it couldn't be
> done.  Luckily chrpath doesn't depend on anything very much, just the
> usual autotools stack, so it doesn't seem like there are very many
> recipes that would have to be chrpath-inhibited.
> 
> (Of course, chrpath itself has quite a high suckage factor and maybe we
> should get/make a better tool while we're worrying about this stuff.)

If we don't have chrpath present it means we need to disable sstate for
all its dependencies and the whole thing got really messy and nasty very
quickly :(.

I've tried to do what you described above and in the end decided it was
a reasonable prerequisite.

If attempting it again I'd probably want to remove the autotooling from
it and turn it into a simple .c file since I'm not sure it derives much
from the autotooling but causes immense pain. Its not exactly a large
code base and I agree with the suckage comment.

Cheers,

Richard

Re: Building hg/help2man not relying on them?

[Phil Blundell]

On Fri, 2011-07-15 at 16:23 +0100, Richard Purdie wrote:
> If we don't have chrpath present it means we need to disable sstate for
> all its dependencies and the whole thing got really messy and nasty very
> quickly :(.

Looking at the output of bitbake -e, the only dependencies for
gettext-native are:

DEPENDS="autoconf-native automake-native libtool-native
gnu-config-native"

and, if I remember right, all of those are basically scripts rather than
compiled binaries (and hence don't have any rpaths to ch.)  So it seems
as though this would actually be a nonissue in practice.

> If attempting it again I'd probably want to remove the autotooling from
> it and turn it into a simple .c file since I'm not sure it derives much
> from the autotooling but causes immense pain. Its not exactly a large
> code base and I agree with the suckage comment.

Yeah, agreed.

p.

Re: Building hg/help2man not relying on them?

[Phil Blundell]

On Fri, 2011-07-15 at 16:38 +0100, Phil Blundell wrote:
> On Fri, 2011-07-15 at 16:23 +0100, Richard Purdie wrote:
> > If we don't have chrpath present it means we need to disable sstate for
> > all its dependencies and the whole thing got really messy and nasty very
> > quickly :(.
> 
> Looking at the output of bitbake -e, the only dependencies for
> gettext-native are:

... irrelevant, of course, but the dependencies for chrpath-native
are...

>DEPENDS="autoconf-native automake-native libtool-native
>gnu-config-native"

p.

Re: Building hg/help2man not relying on them?

[Tom Rini]

On 07/15/2011 08:08 AM, Tom Rini wrote:
> On 07/15/2011 07:43 AM, Mark Hatle wrote:
>> On 7/15/11 9:39 AM, Joshua Lock wrote:
>>> On Thu, 2011-07-14 at 21:56 -0500, Mark Hatle wrote:
>>>> On 7/14/11 9:00 PM, Tom Rini wrote:
>>>>> Hey all,
>>>>>
>>>>> As I work on bringing jenkins up on my stripped down builder machines
>>>>> I've once again run into the "wait, I'm supposed to have installed...?"
>>>>> problem.  Can we switch to building help2man and mercurial rather than
>>>>> making the end user install them?  Perhaps some sort of test for if we
>>>>> find it, ASSUME_PROVIDED it, otherwise build it?
>>>>>
>>>>
>>>> The full sanity list is:
>>>>
>>>> patch help2man diffstat texi2html makeinfo cvs svn bzip2 tar gzip gawk hg
>>>> chrpath wget cpio
>>>>
>>>> Of the above, help2man, texi2html, hg, and chrpath seem to be the ones I usually
>>>> have to find or build myself.
>>>
>>> Originally I built chrpath when I added relocatable.bbclass but then we
>>> wanted to relocate native packages and it got extremely tricky...
>>
>> I wonder if we can do something like pseudo and force chrpath to be built -very-
>> early in the process.. and then have most things have an automatic requirement
>> on chrpath-native...
>>
>> (pseudo of course has the advantage it's NOT used for native packages...)
>>
>> Is the native chrpath usage only in do_package [or later]?  If so, we could
>> probably put a dependency on do_package of chrpath.. with the affect that
>> chrpath would have to be built first...
> 
> IIRC, it's somewhere between really tricky and just not possible to
> nicely shove chrpath-native as a dependency into the graph.  I'm going
> to pause my siteinfo stuff shortly and take a stab at mercurial and
> help2man since I know the recipes exist in oe.dev and this time around
> I'll take a stab at adding stuff to ASSUME_PROVIDED if found (oe.dev
> just has help2man-native in local.conf.sample).

Here's a fun one, I've got the magic done, I think, but I can't test
since there's no hg:// URIs in the metadata atm :)

-- 
Tom Rini
Mentor Graphics Corporation