bitbake.conf: Add git-native to ASSUME_PROVIDED
Originally, git was something new, not installed everywhere and had commandline stability problems. This has changed and git it no longer makes sense to continually build this when the system installed version is likely sufficient.
This speeds up build since recipes no longer have to wait for git-native to build if they're fetched from a git:// SRC_URI.
Also add git to the sanity checks and drop the no unneeded svn reference.
---
meta/classes/sanity.bbclass +1 -1
@@ -2,7 +2,7 @@ # Sanity check the users setup for common misconfigurations # -SANITY_REQUIRED_UTILITIES ?= "patch diffstat texi2html makeinfo svn bzip2 tar gzip gawk chrpath wget cpio" +SANITY_REQUIRED_UTILITIES ?= "patch diffstat texi2html makeinfo git bzip2 tar gzip gawk chrpath wget cpio" def raise_sanity_error(msg, d): if d.getVar("SANITY_USE_EVENTS", True) == "1":
meta/conf/bitbake.conf +1 -0
@@ -152,6 +152,7 @@ DATETIME = "${DATE}${TIME}" # its own in staging ASSUME_PROVIDED = "\ bzip2-native \ + git-native \ grep-native \ diffstat-native \ patch-native \
Quoted 29 lines · Richard Purdie
Originally, git was something new, not installed everywhere and had commandline stability problems. This has changed and git it no longer makes sense to continually build this when the system installed version is likely sufficient.
This speeds up build since recipes no longer have to wait for git-native to build if they're fetched from a
git://SRC_URI.Also add git to the sanity checks and drop the no unneeded svn reference.
Signed-off-by Richard Purdie <[email protected]>---
meta/classes/sanity.bbclass +1
-1@@ -2,7 +2,7 @@ # Sanity check the users setup for common misconfigurations # -SANITY_REQUIRED_UTILITIES ?= "patch diffstat texi2html makeinfo svn bzip2 tar gzip gawk chrpath wget cpio" +SANITY_REQUIRED_UTILITIES ?= "patch diffstat texi2html makeinfo git bzip2 tar gzip gawk chrpath wget cpio" def raise_sanity_error(msg, d): if d.getVar("SANITY_USE_EVENTS", True) == "1":meta/conf/bitbake.conf +0
-0
meta/conf/bitbake.conf DATETIME = "${DATE}${TIME}" · line 158
Quoted 7 lines
meta/conf/bitbake.conf +1
-0@@ -152,6 +152,7 @@ DATETIME = "${DATE}${TIME}" # its own in staging ASSUME_PROVIDED = "\ bzip2-native \ + git-native \ grep-native \ diffstat-native \ patch-native \
possibly a dumb question, but is this the sort of thing one could
extend in one's local.conf file if they were fairly sure their installed versions were compatible?
rday
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Quoted 34 lines · Robert P. J. Day
Quoted 32 lines · Richard Purdie
Originally, git was something new, not installed everywhere and had commandline stability problems. This has changed and git it no longer makes sense to continually build this when the system installed version is likely sufficient.
This speeds up build since recipes no longer have to wait for git-native to build if they're fetched from a
git://SRC_URI.Also add git to the sanity checks and drop the no unneeded svn reference.
Signed-off-by Richard Purdie <[email protected]>---
meta/classes/sanity.bbclass +1
-1@@ -2,7 +2,7 @@ # Sanity check the users setup for common misconfigurations # -SANITY_REQUIRED_UTILITIES ?= "patch diffstat texi2html makeinfo svn bzip2 tar gzip gawk chrpath wget cpio" +SANITY_REQUIRED_UTILITIES ?= "patch diffstat texi2html makeinfo git bzip2 tar gzip gawk chrpath wget cpio" def raise_sanity_error(msg, d): if d.getVar("SANITY_USE_EVENTS", True) == "1":meta/conf/bitbake.conf +0
-0@@ -152,6 +152,7 @@ DATETIME = "${DATE}${TIME}" # its own in staging ASSUME_PROVIDED = "\ bzip2-native \
Quoted 8 lines
meta/conf/bitbake.conf DATETIME = "${DATE}${TIME}" · line 158
Quoted 4 lines
meta/conf/bitbake.conf +1
-0+ git-native \ grep-native \ diffstat-native \ patch-native \possibly a dumb question, but is this the sort of thing one could
extend in one's local.conf file if they were fairly sure their installed versions were compatible?
For some things like git-native, it would be safe. For others like perl-native or python-native, you could seriously shoot yourself in the foot. subversion-native needs to be 1.7+ as an example.
The general idea is correct though, you can extend this from local.conf, yes.
Cheers,
Richard
Quoted 15 lines · Richard Purdie
Quoted 10 lines · Robert P. J. Day
Quoted 7 lines · Richard Purdie
# its own in staging ASSUME_PROVIDED = "\ bzip2-native \ + git-native \ grep-native \ diffstat-native \ patch-native \Quoted 3 lines
possibly a dumb question, but is this the sort of thing one could
extend in one's local.conf file if they were fairly sure their installed versions were compatible?
Quoted 6 lines
For some things like git-native, it would be safe. For others like perl-native or python-native, you could seriously shoot yourself in the foot. subversion-native needs to be 1.7+ as an example.
The general idea is correct though, you can extend this from local.conf, yes.
sure, i appreciate that there's always danger, but with a current
distro, one would think that most standard utilities would be new enough to work just fine. thanks.
rday
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Quoted 8 lines · Richard Purdie
Originally, git was something new, not installed everywhere and had commandline stability problems. This has changed and git it no longer makes sense to continually build this when the system installed version is likely sufficient.
This speeds up build since recipes no longer have to wait for git-native to build if they're fetched from a
git://SRC_URI.Also add git to the sanity checks and drop the no unneeded svn reference.
What about testing the host system for presence of certain things? Then one could
1) yum/apt/etc install the needed items
or
2) Build it if it's not present
-M
Quoted 11 lines · On Tue, 2012-07-10 at 15:00 +0000, McClintock Matthew-B29882 wrote:
Quoted 8 lines · Richard Purdie
Originally, git was something new, not installed everywhere and had commandline stability problems. This has changed and git it no longer makes sense to continually build this when the system installed version is likely sufficient.
This speeds up build since recipes no longer have to wait for git-native to build if they're fetched from a
git://SRC_URI.Also add git to the sanity checks and drop the no unneeded svn reference.
Quoted 8 lines
What about testing the host system for presence of certain things? Then one could
1) yum/apt/etc install the needed items
or
2) Build it if it's not present
Every time we put an if statement in like this, it basically means we should double the amount of QA, one for one path and one for the other.
So whilst I've wondered about it, do we really need to do something like this?
Cheers,
Richard
Quoted 7 lines · Richard Purdie
Quoted 7 lines
What about testing the host system for presence of certain things? Then one could
1) yum/apt/etc install the needed items
or
Quoted 7 lines
Quoted 1 line
2) Build it if it's not present
Every time we put an if statement in like this, it basically means we should double the amount of QA, one for one path and one for the other.
So whilst I've wondered about it, do we really need to do something like this?
Back in the day I used to massively set ASSUME_PROVIDED in local.conf to reduce the amount of -native packages built. When it works it's wonderful, but then you start getting mysterious failures because it turns out that your system's tool has different build options, or is out of date as Poky updated and you didn't notice.
It turned out to be a false economy: by the time I'd installed and verified the packages from Debian I could have had Poky build them for me. :)
Ross
Quoted 5 lines · Richard Purdie
Every time we put an if statement in like this, it basically means we should double the amount of QA, one for one path and one for the other.
So whilst I've wondered about it, do we really need to do something like this?
I don't think we need it, it just has the possibility of improving the initial user experience. What's the QA difference in testing all the various differences in git (or whatever) on the distros we intend to support? In a way ASSUME_PROVIDED += "git" more than doubled the QA ;)
-M
Quoted 19 lines · Richard Purdie
Quoted 18 lines · On Tue, 2012-07-10 at 15:00 +0000, McClintock Matthew-B29882 wrote:
Quoted 8 lines · Richard Purdie
Originally, git was something new, not installed everywhere and had commandline stability problems. This has changed and git it no longer makes sense to continually build this when the system installed version is likely sufficient.
This speeds up build since recipes no longer have to wait for git-native to build if they're fetched from a
git://SRC_URI.Also add git to the sanity checks and drop the no unneeded svn reference.
What about testing the host system for presence of certain things? Then one could
1) yum/apt/etc install the needed items
or
Quoted 7 lines
Quoted 1 line
2) Build it if it's not present
Every time we put an if statement in like this, it basically means we should double the amount of QA, one for one path and one for the other.
So whilst I've wondered about it, do we really need to do something like this?
my opinion, which is mine, is to add a script someone can run that
tells them what appears to be safe to override from their current distro. that way, it's entirely optional and the developer deals with the output at their own risk.
rday
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Quoted 5 lines · Robert P. J. Day
my opinion, which is mine, is to add a script someone can run that
tells them what appears to be safe to override from their current distro. that way, it's entirely optional and the developer deals with the output at their own risk.
who determines the safeness ? thats what double QA RP mentioned is
Quoted 9 lines · Khem Raj
Quoted 5 lines · Robert P. J. Day
my opinion, which is mine, is to add a script someone can run that
tells them what appears to be safe to override from their current distro. that way, it's entirely optional and the developer deals with the output at their own risk.who determines the safeness ? thats what double QA RP mentioned is
If a script says its safe, the bug reports will come in about the script being broken.
Most -native dependencies are either essential (perl, python, dbus, autoconf, automake, libtool, gmp, mpc, mfpr) or trivial. The ones that I really dislike are the ones that hold up the critical path of the build (i.e. libc/toolchain).
git-native is now falling into this category. subversion-native used to be an issue but is rapidly being consigned to the history books.
So bang for buck, git-native makes sense, most other -native dependencies are required at this point. The only two I'd "safely" put in an ASSUME_PROVIDED locally and off the top of my head are flex/bison at this point and those are questionable with some known API gotchas. We've even had problems with things like tar recently. Hard to believe but true and we have the bug reports to prove it.
Cheers,
Richard
Quoted 9 lines · Khem Raj
Quoted 5 lines · Robert P. J. Day
my opinion, which is mine, is to add a script someone can run that
tells them what appears to be safe to override from their current distro. that way, it's entirely optional and the developer deals with the output at their own risk.who determines the safeness ? thats what double QA RP mentioned is
there's no *guarantee* of safeness, just an advisory based on
nothing more than the version number. user makes their own decision and, if it breaks, they get to keep all the pieces.
rday
Signature · 7 lines
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================Quoted 9 lines · On Tue, 2012-07-10 at 15:00 +0000, McClintock Matthew-B29882 wrote:
Quoted 7 lines · Richard Purdie
Originally, git was something new, not installed everywhere and had commandline stability problems. This has changed and git it no longer makes sense to continually build this when the system installed version is likely sufficient.
This speeds up build since recipes no longer have to wait for git-native to build if they're fetched from a
git://SRC_URI.
Quoted 6 lines
Quoted 1 line
Also add git to the sanity checks and drop the no unneeded svn reference.
What about testing the host system for presence of certain things? Then one could
1) yum/apt/etc install the needed items
We do something like this in GNOME/jhbuild, but there's no version comparison:
https://bugzilla.gnome.org/show_bug.cgi?id=564373
This is mainly targeted for system libraries which have pkg-config files, but we're discussing extending it to executables and non-pkg-config headers:
Richard Purdie <[email protected]>
Quoted 4 lines · writes:
Originally, git was something new, not installed everywhere and had commandline stability problems. This has changed and git it no longer makes sense to continually build this when the system installed version is likely sufficient.
Can this really be assumed? Recent bitbake use something like
| git remote add --mirror=fetch
The git version in RHEL 6 or Ubuntu 10 are too old for this and support '--mirror' without a value only.
Enrico
Quoted 9 lines · Enrico Scholz
Richard Purdie <[email protected]>
Quoted 4 lines · writes:
Originally, git was something new, not installed everywhere and had commandline stability problems. This has changed and git it no longer makes sense to continually build this when the system installed version is likely sufficient.
Quoted 6 lines
Can this really be assumed? Recent bitbake use something like
| git remote add --mirror=fetch
The git version in RHEL 6 or Ubuntu 10 are too old for this and support '--mirror' without a value only.
You're right unfortunately, we're going to need to rethink this. I didn't think the git fetcher used any advanced syntax now but it clearly does :(
Does anyone know what the actual version dependency is? I know its after 1.7.3.4 and before 1.7.5.4.
Cheers,
Richard