* Adding support for DirectFB across the board @ 2007-09-23 19:20 shanevolpe 2007-09-24 10:06 ` Richard Purdie 0 siblings, 1 reply; 8+ messages in thread From: shanevolpe @ 2007-09-23 19:20 UTC (permalink / raw) To: openembedded-devel All, I have been adding in support for directFB to as many packages as possible, however one issue I have ran into several times is what do I do when there are packages that can be compiled with X11 or directfb support and then what do you do with packages that may depend on a package compiled with directfb or X11. Ok that was pretty confusing, let me give an example. I have added cairo-directfb which compiles cairo with directfb instead of X11. Next I wanted to add (update) gtk+-directfb to use cairo-directfb instead of cairo. That part was easy I just changed the DEPENDS cairo in gtk+-directfb to cairo-directfb.. The issue came when I noticed that gtk+ also requires pango which requires cairo so what do I do here, do I make a new pango called pango-directfb? It seems like the better thing would be set up a virtual/cairo and set it to either cairo or cairo-directfb. If I go that route how do I set it up so it does not break everyone's build that does not have virtual/cairo set, is there a way to default it to something like cairo? Regards, Shane ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Adding support for DirectFB across the board 2007-09-23 19:20 Adding support for DirectFB across the board shanevolpe @ 2007-09-24 10:06 ` Richard Purdie 2007-09-24 11:08 ` Koen Kooi 0 siblings, 1 reply; 8+ messages in thread From: Richard Purdie @ 2007-09-24 10:06 UTC (permalink / raw) To: openembedded-devel On Sun, 2007-09-23 at 15:20 -0400, shanevolpe@gmail.com wrote: > I have been adding in support for directFB to as many packages as > possible, however one issue I have ran into several times is what do I > do when there are packages that can be compiled with X11 or directfb > support and then what do you do with packages that may depend on a > package compiled with directfb or X11. Ok that was pretty confusing, > let me give an example. > > I have added cairo-directfb which compiles cairo with directfb instead > of X11. Next I wanted to add (update) gtk+-directfb to use > cairo-directfb instead of cairo. That part was easy I just changed > the DEPENDS cairo in gtk+-directfb to cairo-directfb.. The issue came > when I noticed that gtk+ also requires pango which requires cairo so > what do I do here, do I make a new pango called pango-directfb? It > seems like the better thing would be set up a virtual/cairo and set it > to either cairo or cairo-directfb. If I go that route how do I set it > up so it does not break everyone's build that does not have > virtual/cairo set, is there a way to default it to something like > cairo? The thing you need to consider is that pango compiled with a standard cairo is a different package to pango compiled with cairo-directfb. The virtual namespace is used to show things that are equivalent and pango is different to pango-directfb since I couldn't interchange them. You therefore need to create a pango-directfb, ugly as that may be (.inc files can minimise the ugliness though). Cheers, Richard ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Adding support for DirectFB across the board 2007-09-24 10:06 ` Richard Purdie @ 2007-09-24 11:08 ` Koen Kooi 2007-09-24 13:36 ` shanevolpe 0 siblings, 1 reply; 8+ messages in thread From: Koen Kooi @ 2007-09-24 11:08 UTC (permalink / raw) To: openembedded-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Richard Purdie schreef: > On Sun, 2007-09-23 at 15:20 -0400, shanevolpe@gmail.com wrote: >> I have been adding in support for directFB to as many packages as >> possible, however one issue I have ran into several times is what do I >> do when there are packages that can be compiled with X11 or directfb >> support and then what do you do with packages that may depend on a >> package compiled with directfb or X11. Ok that was pretty confusing, >> let me give an example. >> >> I have added cairo-directfb which compiles cairo with directfb instead >> of X11. Next I wanted to add (update) gtk+-directfb to use >> cairo-directfb instead of cairo. That part was easy I just changed >> the DEPENDS cairo in gtk+-directfb to cairo-directfb.. The issue came >> when I noticed that gtk+ also requires pango which requires cairo so >> what do I do here, do I make a new pango called pango-directfb? It >> seems like the better thing would be set up a virtual/cairo and set it >> to either cairo or cairo-directfb. If I go that route how do I set it >> up so it does not break everyone's build that does not have >> virtual/cairo set, is there a way to default it to something like >> cairo? > > The thing you need to consider is that pango compiled with a standard > cairo is a different package to pango compiled with cairo-directfb. > > The virtual namespace is used to show things that are equivalent and > pango is different to pango-directfb since I couldn't interchange them. > > You therefore need to create a pango-directfb, ugly as that may be (.inc > files can minimise the ugliness though). Don't forget to add RCONFLICTS statements, since the resulting binary has the same name (IIRC) regards, Koen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG95qQMkyGM64RGpERAvWrAKCfPDULCnbztGCa/Op+4r6TFR4i3QCeIAoR c6DOEu6KMroHJYKzzbeNZOI= =BNa1 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Adding support for DirectFB across the board 2007-09-24 11:08 ` Koen Kooi @ 2007-09-24 13:36 ` shanevolpe 2007-09-25 22:02 ` Mike (mwester) 0 siblings, 1 reply; 8+ messages in thread From: shanevolpe @ 2007-09-24 13:36 UTC (permalink / raw) To: openembedded-devel; +Cc: openembedded-devel Thanks for the feedback. I have a couple more questions: First should I go into all the pango packages and also add RCONFLICTS="pango-directfb". If I should do that can I just and it to the pango.inc and override it in pango-directfb with RCONFLICTS="pango-directfb" Second, I have a situation were if you build directfb-1.0 and then build directfb-1.1.0 there will be library files for both of them in staging. This is an issue because it seems some packages may use the 1.0 libs and others will use the 1.1 libs causing issues on the target board which is running 1.1.0. How should I handle this, I want to completely remove directfb-1.0 from the staging area when directfb-1.1 is installed. Regards, Shane On 9/24/07, Koen Kooi <k.kooi@student.utwente.nl> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Richard Purdie schreef: > > On Sun, 2007-09-23 at 15:20 -0400, shanevolpe@gmail.com wrote: > >> I have been adding in support for directFB to as many packages as > >> possible, however one issue I have ran into several times is what do I > >> do when there are packages that can be compiled with X11 or directfb > >> support and then what do you do with packages that may depend on a > >> package compiled with directfb or X11. Ok that was pretty confusing, > >> let me give an example. > >> > >> I have added cairo-directfb which compiles cairo with directfb instead > >> of X11. Next I wanted to add (update) gtk+-directfb to use > >> cairo-directfb instead of cairo. That part was easy I just changed > >> the DEPENDS cairo in gtk+-directfb to cairo-directfb.. The issue came > >> when I noticed that gtk+ also requires pango which requires cairo so > >> what do I do here, do I make a new pango called pango-directfb? It > >> seems like the better thing would be set up a virtual/cairo and set it > >> to either cairo or cairo-directfb. If I go that route how do I set it > >> up so it does not break everyone's build that does not have > >> virtual/cairo set, is there a way to default it to something like > >> cairo? > > > > The thing you need to consider is that pango compiled with a standard > > cairo is a different package to pango compiled with cairo-directfb. > > > > The virtual namespace is used to show things that are equivalent and > > pango is different to pango-directfb since I couldn't interchange them. > > > > You therefore need to create a pango-directfb, ugly as that may be (.inc > > files can minimise the ugliness though). > > Don't forget to add RCONFLICTS statements, since the resulting binary has the same name (IIRC) > > regards, > > Koen > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (Darwin) > > iD8DBQFG95qQMkyGM64RGpERAvWrAKCfPDULCnbztGCa/Op+4r6TFR4i3QCeIAoR > c6DOEu6KMroHJYKzzbeNZOI= > =BNa1 > -----END PGP SIGNATURE----- > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > -- Registered Linux User: #293401 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Adding support for DirectFB across the board 2007-09-24 13:36 ` shanevolpe @ 2007-09-25 22:02 ` Mike (mwester) 2007-09-25 23:49 ` shanevolpe 2007-09-26 0:08 ` Paul Sokolovsky 0 siblings, 2 replies; 8+ messages in thread From: Mike (mwester) @ 2007-09-25 22:02 UTC (permalink / raw) To: openembedded-devel Another ugly issue has reared its head. This occurred with the OpenMoko build, but will affect most other distros as well. The problem is that as far as bitbake is concerned, there is absolutely no difference between pango-directfb-1.18.1 and pango-1.18.1, at least in terms of their ability to satisfy dependencies. Thus, the simple act of creating pango-directfb-1.18.1.bb was enough for new builds to select pango-directfb instead of the pango recipe -- so the same build that worked yesterday morning fails in various ways now. On a positive note, at least the problem of incorrect recipe selection is discovered at build time that way -- if it built without error it is possible that the same build done today will have a radically different binary image than one done yesterday, and would go undetected until the binary failed. Note that existing build environments are fine; the selection of pango vs pango-directfb has already been done, and bitbake will be happy that the dependency on pango is met. My first thought was to place my favorite magic incantation (PREFERENCE = "-1") in the pango-directfb recipe, but that matters not. Even such powerful magic cannot overcome this problem. Consulting with the experts on #oe, it seems that the only solution is to add "PREFERRED_PROVIDER" lines for every distro that explicitly select which recipe they want. I simply deleted the *-directfb recipes so I could get the build running, as time was not on my side -- I had 6 hours of build time to catch up on from this problem. A few questions, then: First, this fails the principle of "least surprise". How is it that when I specify a dependency on "pango" that the "pango.bb" recipe is ignored and the "pango-something-different.bb" recipe is used instead? That's just not logical. Shouldn't bitbake select the one who's name matches exactly, when all else is equal? Is it really necessary that pango-directfb and pango provide the same thing, from a "PROVIDES" point-of-view? A simple change in name would avoid this problem completely. I think we're just asking for confusion, and the problems that stem from confusion, by having multiple somethings that claim to provide the same thing. If it is, in fact, necessary that these two recipes provide the same things, then since one is clearly in early development and can destabilize so many different distros, then why can we not use a branch to do the initial testing and development, with a scheduled merge to the mainline so that the distros are all alerted to the need to verify and test when major changes happen? This is a pet peeve of mine - we seem to have frequent "events" that result in mass build breakage where the only fix is to have everyone delete their tmp directories, resync, and build from scratch! As a stockholder in Intel, I am grateful for the resulting increased demand for quad-core CPUs, but as a developer, each of these surprise events takes a full day of productivity away. I think all of us value the time we spend on this hobby, and doing disruptive changes on a branch in isolation just seems to me to be a respectful, and decent thing for each developer to do as part of being a community member. JMNSHO. Finally, can we have bitbake be a bit more "in your face" about its decisions when there are no external criteria provided? A warning to say "Hey! I've just selected "pango-directfb" to satisfy the dependency for "pango" -- but you should know that "pango" would equally-well satisfy the dependency, and I picked one only because you didn't provide any hints to select one over the other!"? Thanks, Mike (mwester) On 9/24/07, shanevolpe@gmail.com wrote: > Thanks for the feedback. I have a couple more questions: > > First should I go into all the pango packages and also add > RCONFLICTS="pango-directfb". If I should do that can I just and it to > the pango.inc and override it in pango-directfb with > RCONFLICTS="pango-directfb" > > Second, I have a situation were if you build directfb-1.0 and then > build directfb-1.1.0 there will be library files for both of them in > staging. This is an issue because it seems some packages may use the > 1.0 libs and others will use the 1.1 libs causing issues on the target > board which is running 1.1.0. How should I handle this, I want to > completely remove directfb-1.0 from the staging area when directfb-1.1 > is installed. > Regards, > Shane > > > On 9/24/07, Koen Kooi <k.kooi@student.utwente.nl> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Richard Purdie schreef: > > > On Sun, 2007-09-23 at 15:20 -0400, shanevolpe@gmail.com wrote: > > >> I have been adding in support for directFB to as many packages as > > >> possible, however one issue I have ran into several times is what do I > > >> do when there are packages that can be compiled with X11 or directfb > > >> support and then what do you do with packages that may depend on a > > >> package compiled with directfb or X11. Ok that was pretty confusing, > > >> let me give an example. > > >> > > >> I have added cairo-directfb which compiles cairo with directfb instead > > >> of X11. Next I wanted to add (update) gtk+-directfb to use > > >> cairo-directfb instead of cairo. That part was easy I just changed > > >> the DEPENDS cairo in gtk+-directfb to cairo-directfb.. The issue came > > >> when I noticed that gtk+ also requires pango which requires cairo so > > >> what do I do here, do I make a new pango called pango-directfb? It > > >> seems like the better thing would be set up a virtual/cairo and set it > > >> to either cairo or cairo-directfb. If I go that route how do I set it > > >> up so it does not break everyone's build that does not have > > >> virtual/cairo set, is there a way to default it to something like > > >> cairo? > > > > > > The thing you need to consider is that pango compiled with a standard > > > cairo is a different package to pango compiled with cairo-directfb. > > > > > > The virtual namespace is used to show things that are equivalent and > > > pango is different to pango-directfb since I couldn't interchange them. > > > > > > You therefore need to create a pango-directfb, ugly as that may be (.inc > > > files can minimise the ugliness though). > > > > Don't forget to add RCONFLICTS statements, since the resulting binary has the same name (IIRC) > > > > regards, > > > > Koen ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Adding support for DirectFB across the board 2007-09-25 22:02 ` Mike (mwester) @ 2007-09-25 23:49 ` shanevolpe 2007-09-26 0:08 ` Paul Sokolovsky 1 sibling, 0 replies; 8+ messages in thread From: shanevolpe @ 2007-09-25 23:49 UTC (permalink / raw) To: openembedded-devel Mike, Thanks for the feedback, I will remove pang-directfb until I figure out the correct way to add it. In truth we should NOT need pango-directfb but the issue is pango has cairo as a dependency (even though it is NOT needed for build) and cairo must be built with directfb support so I added cairo-directfb. I did not want to disturb an existing package so I created pango-directfb instead of removing cairo from pango's dependencies. If I recall correctly there were some X packages that were in pango's dependencies (also not needed to build pango) and I did NOT want to remove them either. I would love more feedback on how I should handle this issue. Regards, Shane On 9/25/07, Mike (mwester) <mwester@dls.net> wrote: > Another ugly issue has reared its head. This occurred with the OpenMoko > build, but will affect most other distros as well. The problem is that as > far as bitbake is concerned, there is absolutely no difference between > pango-directfb-1.18.1 and pango-1.18.1, at least in terms of their ability > to satisfy dependencies. > > Thus, the simple act of creating pango-directfb-1.18.1.bb was enough for new > builds to select pango-directfb instead of the pango recipe -- so the same > build that worked yesterday morning fails in various ways now. On a > positive note, at least the problem of incorrect recipe selection is > discovered at build time that way -- if it built without error it is > possible that the same build done today will have a radically different > binary image than one done yesterday, and would go undetected until the > binary failed. Note that existing build environments are fine; the > selection of pango vs pango-directfb has already been done, and bitbake will > be happy that the dependency on pango is met. > > My first thought was to place my favorite magic incantation (PREFERENCE = > "-1") in the pango-directfb recipe, but that matters not. Even such > powerful magic cannot overcome this problem. > > Consulting with the experts on #oe, it seems that the only solution is to > add "PREFERRED_PROVIDER" lines for every distro that explicitly select which > recipe they want. I simply deleted the *-directfb recipes so I could get > the build running, as time was not on my side -- I had 6 hours of build time > to catch up on from this problem. > > A few questions, then: > > First, this fails the principle of "least surprise". How is it that when I > specify a dependency on "pango" that the "pango.bb" recipe is ignored and > the "pango-something-different.bb" recipe is used instead? That's just not > logical. Shouldn't bitbake select the one who's name matches exactly, when > all else is equal? > > Is it really necessary that pango-directfb and pango provide the same thing, > from a "PROVIDES" point-of-view? A simple change in name would avoid this > problem completely. I think we're just asking for confusion, and the > problems that stem from confusion, by having multiple somethings that claim > to provide the same thing. > > If it is, in fact, necessary that these two recipes provide the same things, > then since one is clearly in early development and can destabilize so many > different distros, then why can we not use a branch to do the initial > testing and development, with a scheduled merge to the mainline so that the > distros are all alerted to the need to verify and test when major changes > happen? This is a pet peeve of mine - we seem to have frequent "events" > that result in mass build breakage where the only fix is to have everyone > delete their tmp directories, resync, and build from scratch! As a > stockholder in Intel, I am grateful for the resulting increased demand for > quad-core CPUs, but as a developer, each of these surprise events takes a > full day of productivity away. I think all of us value the time we spend on > this hobby, and doing disruptive changes on a branch in isolation just seems > to me to be a respectful, and decent thing for each developer to do as part > of being a community member. JMNSHO. > > Finally, can we have bitbake be a bit more "in your face" about its > decisions when there are no external criteria provided? A warning to say > "Hey! I've just selected "pango-directfb" to satisfy the dependency for > "pango" -- but you should know that "pango" would equally-well satisfy the > dependency, and I picked one only because you didn't provide any hints to > select one over the other!"? > > Thanks, > Mike (mwester) > > On 9/24/07, shanevolpe@gmail.com wrote: > > Thanks for the feedback. I have a couple more questions: > > > > First should I go into all the pango packages and also add > > RCONFLICTS="pango-directfb". If I should do that can I just and it to > > the pango.inc and override it in pango-directfb with > > RCONFLICTS="pango-directfb" > > > > Second, I have a situation were if you build directfb-1.0 and then > > build directfb-1.1.0 there will be library files for both of them in > > staging. This is an issue because it seems some packages may use the > > 1.0 libs and others will use the 1.1 libs causing issues on the target > > board which is running 1.1.0. How should I handle this, I want to > > completely remove directfb-1.0 from the staging area when directfb-1.1 > > is installed. > > Regards, > > Shane > > > > > > On 9/24/07, Koen Kooi <k.kooi@student.utwente.nl> wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Richard Purdie schreef: > > > > On Sun, 2007-09-23 at 15:20 -0400, shanevolpe@gmail.com wrote: > > > >> I have been adding in support for directFB to as many packages as > > > >> possible, however one issue I have ran into several times is what do > I > > > >> do when there are packages that can be compiled with X11 or directfb > > > >> support and then what do you do with packages that may depend on a > > > >> package compiled with directfb or X11. Ok that was pretty confusing, > > > >> let me give an example. > > > >> > > > >> I have added cairo-directfb which compiles cairo with directfb > instead > > > >> of X11. Next I wanted to add (update) gtk+-directfb to use > > > >> cairo-directfb instead of cairo. That part was easy I just changed > > > >> the DEPENDS cairo in gtk+-directfb to cairo-directfb.. The issue > came > > > >> when I noticed that gtk+ also requires pango which requires cairo so > > > >> what do I do here, do I make a new pango called pango-directfb? It > > > >> seems like the better thing would be set up a virtual/cairo and set > it > > > >> to either cairo or cairo-directfb. If I go that route how do I set > it > > > >> up so it does not break everyone's build that does not have > > > >> virtual/cairo set, is there a way to default it to something like > > > >> cairo? > > > > > > > > The thing you need to consider is that pango compiled with a standard > > > > cairo is a different package to pango compiled with cairo-directfb. > > > > > > > > The virtual namespace is used to show things that are equivalent and > > > > pango is different to pango-directfb since I couldn't interchange > them. > > > > > > > > You therefore need to create a pango-directfb, ugly as that may be > (.inc > > > > files can minimise the ugliness though). > > > > > > Don't forget to add RCONFLICTS statements, since the resulting binary > has the same name (IIRC) > > > > > > regards, > > > > > > Koen > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > -- Registered Linux User: #293401 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Adding support for DirectFB across the board 2007-09-25 22:02 ` Mike (mwester) 2007-09-25 23:49 ` shanevolpe @ 2007-09-26 0:08 ` Paul Sokolovsky 2007-09-26 1:47 ` Mike (mwester) 1 sibling, 1 reply; 8+ messages in thread From: Paul Sokolovsky @ 2007-09-26 0:08 UTC (permalink / raw) To: Mike (mwester); +Cc: openembedded-devel Hello Mike, Wednesday, September 26, 2007, 1:02:43 AM, you wrote: > Another ugly issue has reared its head. This occurred with the OpenMoko > build, but will affect most other distros as well. The problem is that as > far as bitbake is concerned, there is absolutely no difference between > pango-directfb-1.18.1 and pango-1.18.1, at least in terms of their ability > to satisfy dependencies. > Thus, the simple act of creating pango-directfb-1.18.1.bb was enough for new > builds to select pango-directfb instead of the pango recipe -- so the same > build that worked yesterday morning fails in various ways now. On a > positive note, at least the problem of incorrect recipe selection is > discovered at build time that way -- if it built without error it is > possible that the same build done today will have a radically different > binary image than one done yesterday, and would go undetected until the > binary failed. Note that existing build environments are fine; the > selection of pango vs pango-directfb has already been done, and bitbake will > be happy that the dependency on pango is met. > My first thought was to place my favorite magic incantation (PREFERENCE = > "-1") in the pango-directfb recipe, but that matters not. Even such > powerful magic cannot overcome this problem. I faced this issue too and chatted about it with Richard Purdie, but I believe it isn't even submitted as as bitbake bug. But in general, this should be the right and the most logic solution - unless PREFERRED_PROVIDER explicitly selects some variant, one with higher preference should be used, not random. > Consulting with the experts on #oe, it seems that the only solution is to > add "PREFERRED_PROVIDER" lines for every distro that explicitly select which > recipe they want. I simply deleted the *-directfb recipes so I could get > the build running, as time was not on my side -- I had 6 hours of build time > to catch up on from this problem. > A few questions, then: > First, this fails the principle of "least surprise". How is it that when I > specify a dependency on "pango" that the "pango.bb" recipe is ignored and > the "pango-something-different.bb" recipe is used instead? That's just not > logical. Shouldn't bitbake select the one who's name matches exactly, when > all else is equal? Mildly good heuristic too, but using DEFAULT_PREFERENCE would be even better. > Is it really necessary that pango-directfb and pango provide the same thing, > from a "PROVIDES" point-of-view? Apparently yes, as they provide the same facility/functionality, but different implementation of it. It is the essence of PROVIDES. And we shouldn't give up this idea simply because current version of OE/bitbake doesn't do it right. > A simple change in name would avoid this > problem completely. I think we're just asking for confusion, and the > problems that stem from confusion, by having multiple somethings that claim > to provide the same thing. > If it is, in fact, necessary that these two recipes provide the same things, > then since one is clearly in early development and can destabilize so many > different distros, then why can we not use a branch to do the initial > testing and development, with a scheduled merge to the mainline so that the > distros are all alerted to the need to verify and test when major changes > happen? This is a pet peeve of mine - we seem to have frequent "events" > that result in mass build breakage where the only fix is to have everyone > delete their tmp directories, resync, and build from scratch! As a > stockholder in Intel, I am grateful for the resulting increased demand for > quad-core CPUs, but as a developer, each of these surprise events takes a > full day of productivity away. I think all of us value the time we spend on > this hobby, and doing disruptive changes on a branch in isolation just seems > to me to be a respectful, and decent thing for each developer to do as part > of being a community member. JMNSHO. With a good chance, that won't improve integral productivity of OE developers, just will make breakages "more scheduled". At least not before we'll make tools and conventions right. > Finally, can we have bitbake be a bit more "in your face" about its > decisions when there are no external criteria provided? A warning to say > "Hey! I've just selected "pango-directfb" to satisfy the dependency for > "pango" -- but you should know that "pango" would equally-well satisfy the > dependency, and I picked one only because you didn't provide any hints to > select one over the other!"? That's exactly what it does - it says something like "Consider defining PREFERRED_PROVIDER". It's notice though, IIRC. > Thanks, > Mike (mwester) [] -- Best regards, Paul mailto:pmiscml@gmail.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Adding support for DirectFB across the board 2007-09-26 0:08 ` Paul Sokolovsky @ 2007-09-26 1:47 ` Mike (mwester) 0 siblings, 0 replies; 8+ messages in thread From: Mike (mwester) @ 2007-09-26 1:47 UTC (permalink / raw) To: Paul Sokolovsky; +Cc: openembedded-devel > That's exactly what it does - it says something like "Consider > defining PREFERRED_PROVIDER". It's notice though, IIRC. I know that message - I've seen that in the past (and have taken action to resolve the ambiguity it was pointing out). But bitbake doesn't print that message in this situation. :( Mike (mwester) ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-09-26 1:51 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-09-23 19:20 Adding support for DirectFB across the board shanevolpe 2007-09-24 10:06 ` Richard Purdie 2007-09-24 11:08 ` Koen Kooi 2007-09-24 13:36 ` shanevolpe 2007-09-25 22:02 ` Mike (mwester) 2007-09-25 23:49 ` shanevolpe 2007-09-26 0:08 ` Paul Sokolovsky 2007-09-26 1:47 ` Mike (mwester)
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.