Building hg/help2man not relying on them?
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?
Signature · 2 lines
Tom Rini Mentor Graphics Corporation
Quoted 8 lines · 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_PROVIDEDit, 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
Quoted 10 lines · Mark Hatle
Quoted 8 lines · 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_PROVIDEDit, otherwise build it?
Quoted 7 lines
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
Signature · 3 lines
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology CentreQuoted 13 lines · Joshua Lock
Quoted 12 lines · Mark Hatle
Quoted 8 lines · 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_PROVIDEDit, otherwise build it?The full sanity list is:
Quoted 8 lines
Quoted 5 lines
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
Quoted 2 lines
Joshua
Quoted 27 lines · Mark Hatle
Quoted 13 lines · Joshua Lock
Quoted 12 lines · Mark Hatle
Quoted 8 lines · 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_PROVIDEDit, otherwise build it?The full sanity list is:
Quoted 8 lines
Quoted 5 lines
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...
Quoted 5 lines
(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 ondo_packageof 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).
Signature · 2 lines
Tom Rini Mentor Graphics Corporation
Quoted 2 lines · Tom Rini
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.
Quoted 12 lines · Phil Blundell
Quoted 2 lines · Tom Rini
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.
Quoted 2 lines
(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
Quoted 3 lines · Richard Purdie
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.
Quoted 4 lines
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.
Quoted 7 lines · Phil Blundell
Quoted 3 lines · Richard Purdie
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...
Quoted 2 lines
DEPENDS="autoconf-native automake-native libtool-native gnu-config-native"
p.
Quoted 34 lines · Tom Rini
Quoted 27 lines · Mark Hatle
Quoted 13 lines · Joshua Lock
Quoted 12 lines · Mark Hatle
Quoted 8 lines · 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_PROVIDEDit, otherwise build it?The full sanity list is:
Quoted 8 lines
Quoted 5 lines
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...
Quoted 5 lines
(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 ondo_packageof chrpath.. with the affect that chrpath would have to be built first...
Quoted 6 lines
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_PROVIDEDif 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 :)
Signature · 2 lines
Tom Rini Mentor Graphics Corporation