| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #oe | 00:05 | |
| *** paulg <paulg!~paulg@24-212-160-219.cable.teksavvy.com> has quit IRC (Ping timeout: 256 seconds) | 00:10 | |
| *** paulg <paulg!~paulg@24-212-160-219.cable.teksavvy.com> has joined #oe | 00:11 | |
| *** nslu2-log_ <nslu2-log_!~nslu2-log@leia.nas-admin.org> has joined #oe | 01:05 | |
| *** nslu2-log <nslu2-log!~nslu2-log@leia.nas-admin.org> has quit IRC (Read error: Connection reset by peer) | 01:05 | |
| *** nslu2-log_ is now known as nslu2-log | 01:06 | |
| *** camus <camus!~Instantbi@117.143.3.97> has joined #oe | 02:16 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 02:19 | |
| *** rber|res <rber|res!~rber|res@62-46-95-169.adsl.highway.telekom.at> has joined #oe | 02:32 | |
| *** RobertBerger <RobertBerger!~rber|res@62-46-95-169.adsl.highway.telekom.at> has quit IRC (Ping timeout: 264 seconds) | 02:34 | |
| *** camus1 <camus1!~Instantbi@2409:8a1e:9122:21b0:4589:65c0:760b:5ae3> has joined #oe | 02:47 | |
| *** camus <camus!~Instantbi@117.143.3.97> has quit IRC (Ping timeout: 252 seconds) | 02:49 | |
| *** camus1 is now known as camus | 02:49 | |
| *** umbramalison <umbramalison!~umbramali@188.74.90.42> has quit IRC (Quit: %So long and thanks for all the fish%) | 02:49 | |
| *** umbramalison <umbramalison!~umbramali@188.74.90.42> has joined #oe | 02:49 | |
| *** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has joined #oe | 04:02 | |
| *** rcw <rcw!~rcwoolley@216.154.26.130> has joined #oe | 04:35 | |
| *** RobW <RobW!~rcwoolley@216.154.26.130> has quit IRC (Ping timeout: 268 seconds) | 04:38 | |
| *** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has quit IRC (Ping timeout: 268 seconds) | 05:15 | |
| *** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has joined #oe | 07:10 | |
| *** camus <camus!~Instantbi@2409:8a1e:9122:21b0:4589:65c0:760b:5ae3> has quit IRC (Ping timeout: 260 seconds) | 07:20 | |
| *** rob_w_ <rob_w_!~bob@host-82-135-31-73.customer.m-online.net> has joined #oe | 07:27 | |
| *** rob_w_ <rob_w_!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Client Quit) | 07:29 | |
| *** rob_w_ <rob_w_!~bob@host-82-135-31-73.customer.m-online.net> has joined #oe | 07:31 | |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has joined #oe | 07:31 | |
| *** rob_w_ <rob_w_!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Client Quit) | 07:32 | |
| *** camus <camus!~Instantbi@117.143.3.97> has joined #oe | 07:38 | |
| *** mckoan|away is now known as mckoan | 07:46 | |
| mckoan | good morning | 07:46 |
|---|---|---|
| *** dl9pf[m] <dl9pf[m]!~dl9pfmatr@2001:470:69fc:105::9a8> has joined #oe | 07:47 | |
| *** pbergin <pbergin!~pbergin@c-799071d5.44006-0-69747578.bbcust.telenor.se> has joined #oe | 07:52 | |
| *** cmhe <cmhe!~cmhe@dslb-088-077-007-107.088.077.pools.vodafone-ip.de> has joined #oe | 07:56 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has joined #oe | 08:01 | |
| *** frieder <frieder!~frieder@200116b8244093810000000000001cba.dip.versatel-1u1.de> has joined #oe | 09:03 | |
| *** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has quit IRC (Remote host closed the connection) | 09:29 | |
| *** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has joined #oe | 09:33 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has joined #oe | 09:58 | |
| *** michalkotyla <michalkotyla!~michalkot@84-10-27-202.static.chello.pl> has joined #oe | 11:13 | |
| *** michalkotyla <michalkotyla!~michalkot@84-10-27-202.static.chello.pl> has quit IRC (Remote host closed the connection) | 11:17 | |
| *** michalkotyla <michalkotyla!~michalkot@84-10-27-202.static.chello.pl> has joined #oe | 11:19 | |
| *** michalkotyla <michalkotyla!~michalkot@84-10-27-202.static.chello.pl> has quit IRC (Quit: Connection closed) | 11:49 | |
| *** michalkotyla <michalkotyla!~michalkot@84-10-27-202.static.chello.pl> has joined #oe | 11:50 | |
| *** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has quit IRC (Ping timeout: 260 seconds) | 12:32 | |
| *** rber|res <rber|res!~rber|res@62-46-95-169.adsl.highway.telekom.at> has quit IRC (Ping timeout: 264 seconds) | 12:52 | |
| *** michalkotyla <michalkotyla!~michalkot@84-10-27-202.static.chello.pl> has quit IRC (Quit: Connection closed) | 12:56 | |
| *** nslu2-log <nslu2-log!~nslu2-log@leia.nas-admin.org> has quit IRC (Quit: Disconnecting from stoned server.) | 13:02 | |
| *** nslu2-log <nslu2-log!~nslu2-log@leia.nas-admin.org> has joined #oe | 13:02 | |
| *** rber|res <rber|res!~rber|res@2001:871:20c:5a8:78de:ffc:a2cf:d97f> has joined #oe | 13:09 | |
| *** RobertBerger <RobertBerger!~rber|res@62-46-91-193.adsl.highway.telekom.at> has joined #oe | 13:10 | |
| *** rber|res <rber|res!~rber|res@2001:871:20c:5a8:78de:ffc:a2cf:d97f> has quit IRC (Ping timeout: 260 seconds) | 13:13 | |
| *** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has joined #oe | 13:13 | |
| *** kanavin_ <kanavin_!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has quit IRC (Remote host closed the connection) | 13:40 | |
| *** kanavin <kanavin!~Alexander@2a02:2454:29b:3b00:d35d:e3cf:58b5:748b> has joined #oe | 13:42 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #oe | 13:54 | |
| cmhe | Does bitbake offer a way to list all available build targets? So a list that would include all PROVIDES for all not skipped recipes including the `virtual/*` targets and possible `world` as well? | 14:06 |
| *** Net147 <Net147!~Net147@user/net147> has quit IRC (Ping timeout: 264 seconds) | 14:07 | |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-19-184-147-77-157.dsl.bell.ca> has joined #oe | 14:25 | |
| rburton | bitbake-layers show-recipes | 14:30 |
| cmhe | that only shows recipes, but not all build targets. It wouldn't show `virtual/kernel` for instance, but you can use it to build the currently preferred kernel recipe. | 14:32 |
| cmhe | It also doesn't list `perl-native` so even `pn-buildlist` after `bitbake -g world` is more complete... | 14:37 |
| cmhe | `bitbake -s` also shows `perl-native` but still no `virtual/*` packages or `world`... | 14:47 |
| *** rob_w <rob_w!~bob@host-82-135-31-73.customer.m-online.net> has quit IRC (Quit: Leaving) | 14:57 | |
| *** camus <camus!~Instantbi@117.143.3.97> has quit IRC (Remote host closed the connection) | 16:02 | |
| *** Net147 <Net147!~Net147@167-179-157-192.a7b39d.syd.nbn.aussiebb.net> has joined #oe | 16:13 | |
| *** alimon <alimon!~alimon@2806:10b7:3:afd6:2c32:cfff:fe8e:de1f> has quit IRC (Remote host closed the connection) | 16:18 | |
| *** kmaincent[m] <kmaincent[m]!~kmaincent@2001:470:69fc:105::2:825d> has joined #oe | 16:18 | |
| *** alimon <alimon!~alimon@2806:10b7:3:afd6:2c32:cfff:fe8e:de1f> has joined #oe | 16:21 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has joined #oe | 16:21 | |
| *** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has quit IRC (Ping timeout: 268 seconds) | 16:28 | |
| *** frieder <frieder!~frieder@200116b8244093810000000000001cba.dip.versatel-1u1.de> has quit IRC (Remote host closed the connection) | 16:28 | |
| *** florian <florian!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Quit: Ex-Chat) | 17:33 | |
| *** florian_kc <florian_kc!~florian@port-217-146-132-69.static.as20676.net> has quit IRC (Ping timeout: 260 seconds) | 17:36 | |
| *** esben[m] <esben[m]!~esbengean@2001:470:69fc:105::1:3510> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** Crofton[m] <Crofton[m]!~croftongn@2001:470:69fc:105::9a7> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** khem <khem!~khem@2001:470:69fc:105::b81> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** stefan-schmidt <stefan-schmidt!~stefan-sc@2001:470:69fc:105::a66> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** Tartarus <Tartarus!~tr1265@2001:470:69fc:105::1:4b21> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** denisoft81[m] <denisoft81[m]!~denisoft8@2001:470:69fc:105::2:4f06> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** rake[m] <rake[m]!~M0xrakema@2001:470:69fc:105::1:f2c2> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** rmndbnnn[m] <rmndbnnn[m]!~rmndbnnnm@2001:470:69fc:105::2:c91d> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** dl9pf[m] <dl9pf[m]!~dl9pfmatr@2001:470:69fc:105::9a8> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** kmaincent[m] <kmaincent[m]!~kmaincent@2001:470:69fc:105::2:825d> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** berton[m] <berton[m]!~berton@2001:470:69fc:105::ce36> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** cb5r <cb5r!~cb5r@user/cb5r> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** pmf[m] <pmf[m]!~pmfmatrix@2001:470:69fc:105::93ed> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** gate32[m] <gate32[m]!~gate32mat@2001:470:69fc:105::9e3> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** FredericOuellet[ <FredericOuellet[!~tazura562@2001:470:69fc:105::1:3c31> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** ThomasRoos[m] <ThomasRoos[m]!~thomasroo@2001:470:69fc:105::2:2017> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** styloge[m] <styloge[m]!~stylogema@2001:470:69fc:105::2:bfe3> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** Saur[m] <Saur[m]!~saur2000m@2001:470:69fc:105::dce> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** olku[m] <olku[m]!~olkumatri@2001:470:69fc:105::2:b023> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:37 | |
| *** cmhe <cmhe!~cmhe@dslb-088-077-007-107.088.077.pools.vodafone-ip.de> has quit IRC (Ping timeout: 255 seconds) | 17:40 | |
| *** mckoan is now known as mckoan|away | 17:40 | |
| *** Crofton[m] <Crofton[m]!~croftongn@2001:470:69fc:105::9a7> has joined #oe | 17:42 | |
| *** Tartarus <Tartarus!~tr1265@2001:470:69fc:105::1:4b21> has joined #oe | 17:47 | |
| *** shoragan[m] <shoragan[m]!~shoraganm@2001:470:69fc:105::39> has joined #oe | 17:47 | |
| *** esben[m] <esben[m]!~esbengean@2001:470:69fc:105::1:3510> has joined #oe | 17:47 | |
| *** Saur[m] <Saur[m]!~saur2000m@2001:470:69fc:105::dce> has joined #oe | 17:47 | |
| *** stefan-schmidt <stefan-schmidt!~stefan-sc@2001:470:69fc:105::a66> has joined #oe | 17:47 | |
| *** khem <khem!~khem@2001:470:69fc:105::b81> has joined #oe | 17:47 | |
| *** denisoft81[m] <denisoft81[m]!~denisoft8@2001:470:69fc:105::2:4f06> has joined #oe | 17:47 | |
| *** olku[m] <olku[m]!~olkumatri@2001:470:69fc:105::2:b023> has joined #oe | 17:48 | |
| *** pmf[m] <pmf[m]!~pmfmatrix@2001:470:69fc:105::93ed> has joined #oe | 17:48 | |
| *** rmndbnnn[m] <rmndbnnn[m]!~rmndbnnnm@2001:470:69fc:105::2:c91d> has joined #oe | 17:48 | |
| *** FredericOuellet[ <FredericOuellet[!~tazura562@2001:470:69fc:105::1:3c31> has joined #oe | 17:48 | |
| *** rake[m] <rake[m]!~M0xrakema@2001:470:69fc:105::1:f2c2> has joined #oe | 17:48 | |
| *** kmaincent[m] <kmaincent[m]!~kmaincent@2001:470:69fc:105::2:825d> has joined #oe | 17:48 | |
| *** styloge[m] <styloge[m]!~stylogema@2001:470:69fc:105::2:bfe3> has joined #oe | 17:48 | |
| *** gate32[m] <gate32[m]!~gate32mat@2001:470:69fc:105::9e3> has joined #oe | 17:48 | |
| *** hmw[m] <hmw[m]!~hmwmatrix@2001:470:69fc:105::3c7c> has joined #oe | 17:48 | |
| *** cb5r <cb5r!~cb5r@user/cb5r> has joined #oe | 17:48 | |
| *** ThomasRoos[m] <ThomasRoos[m]!~thomasroo@2001:470:69fc:105::2:2017> has joined #oe | 17:48 | |
| *** berton[m] <berton[m]!~berton@2001:470:69fc:105::ce36> has joined #oe | 17:48 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has quit IRC (Quit: Leaving.) | 18:45 | |
| *** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has joined #oe | 18:45 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-135-103-035.93.135.pool.telefonica.de> has joined #oe | 19:22 | |
| *** davidlt <davidlt!~davidlt@78-63-27-146.static.zebra.lt> has quit IRC (Ping timeout: 260 seconds) | 19:47 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-135-103-035.93.135.pool.telefonica.de> has quit IRC (Ping timeout: 260 seconds) | 19:50 | |
| *** leon-anavi <leon-anavi!~Leon@46.55.231.62> has quit IRC (Quit: Leaving) | 19:59 | |
| *** sakoman <sakoman!~steve@dhcp-72-253-6-214.hawaiiantel.net> has joined #oe | 20:10 | |
| *** darkestdot <darkestdot!uid578730@id-578730.uxbridge.irccloud.com> has joined #oe | 20:18 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-135-103-035.93.135.pool.telefonica.de> has joined #oe | 20:27 | |
| *** umbramalison <umbramalison!~umbramali@188.74.90.42> has quit IRC (Quit: %So long and thanks for all the fish%) | 20:40 | |
| *** umbramalison <umbramalison!~umbramali@188.74.90.42> has joined #oe | 20:41 | |
| *** florian_kc <florian_kc!~florian@dynamic-093-135-103-035.93.135.pool.telefonica.de> has quit IRC (Ping timeout: 246 seconds) | 22:01 | |
| Jin^eLD | is it somehow possible to conditionally modify the DEPENDS of a package, making the decision dependend on changes in the git repo which the SRC_URI is pointing to? | 22:39 |
| *** dl9pf[m] <dl9pf[m]!~dl9pfmatr@2001:470:69fc:105::9a8> has joined #oe | 22:39 | |
| Jin^eLD | I mean at build time, not as a fixed distro config | 22:39 |
| Jin^eLD | basically I have a terrible setup which I can not get rid of, where auth tokens are being commited to a submodule twice per day and those are needed to access some npm dependencies which the main recipe needs; of course this is causing unnecessary builds... so I am figuring if I could somehow first evaluate if sources for the main recipe have changed, and if they did - only then trigger the build of | 22:40 |
| Jin^eLD | the dependency package which would fetch the access token needed for building | 22:40 |
| RP | Jin^eLD: something like DEPENDS = "${@'A' if 'B' in d.getVar('SRC_URI') else 'C'}" | 23:00 |
| RP | Jin^eLD: ah, you said in the remote repo. That is harder :( | 23:01 |
| RP | Jin^eLD: you could probably put a function call in there which checked but it wouldn't be nice or perform well | 23:01 |
| Jin^eLD | yes.. its terrible, two git repos, one is meant to be a submodule but I split them up into two independent packages | 23:02 |
| Jin^eLD | into two recipes I mean | 23:02 |
| Jin^eLD | so I am looking for if SRC_URI of A says stuff changed, then DEPENDS = "add B", otherwise don't | 23:02 |
| Jin^eLD | RP: I wonder if there is an event which could help me? looing into bb.event now, but not sure if that makes sense | 23:06 |
| Jin^eLD | or anything I could hook onto that decides that "my code has changed due to new commits, I need to rebuild" - thats where I would try to hack DEPENDS | 23:07 |
| RP | Jin^eLD: you basically need to make bitbake parse the recipe every time to trigger the check | 23:07 |
| Jin^eLD | the "A" recipe is part of my image, so it would get looked at as a dependency to the image | 23:08 |
| Jin^eLD | the idea is that inside "A" I want to DEPEND on "B" only if "A" sees it has new git commits in its SRC_URI repo | 23:08 |
| RP | Jin^eLD: I get the idea but remember that bitbake caches DEPENDS, it doesn't reparse the recipe on every call. It also has no idea when it needs to reparse the recipe | 23:09 |
| RP | so in order to make DEPENDS change, it would have to reparse that recipe every time | 23:10 |
| Jin^eLD | ooh, thats what you meant | 23:10 |
| Jin^eLD | right, now I get it | 23:10 |
| *** cmhe <cmhe!~cmhe@dslb-088-077-007-107.088.077.pools.vodafone-ip.de> has joined #oe | 23:10 | |
| Jin^eLD | so one more "how to do it" question | 23:10 |
| RP | BB_DONT_CACHE = "1" in the recipe | 23:11 |
| Jin^eLD | oh that's simple, cool :) | 23:11 |
| Jin^eLD | so then the more difficult part I guess - any hint where to hook into the decision if a rebuild of A is needed due to its own SRC_URI change or not? | 23:12 |
| Jin^eLD | or rather contents of the SRC_URI | 23:12 |
| RP | Jin^eLD: in most cases people make the recipe AUTOREV since if the upstream revision changes, they want the rebuild | 23:13 |
| RP | autorev recipes automatically set don't cache | 23:13 |
| Jin^eLD | that would work on the devel setup, but not on a release setup where I pin down what to build using tags, however that damn auth token repo has to remain AUTOREV of course | 23:14 |
| Jin^eLD | I do not care if the token repo gets rebuilt too often, that is fast and its not part of the resulting image | 23:14 |
| Jin^eLD | i.e. thats my "B" package in the scenario | 23:14 |
| fray | in meta-openamp we just moved to a discrete <recipe> and <recipe>-dev that disable the -dev version unless set in preferred version.. that seems to work well with the AUTOREV | 23:14 |
| fray | sorry not preferred version, I mean preferred provider | 23:15 |
| * RP -> afk | 23:15 | |
| Jin^eLD | fray: could you elaborate a bit, I am not yet getting it | 23:15 |
| fray | (modeled after linux-yocto and linux-yocto-dev) | 23:15 |
| Jin^eLD | let me look at linux-yocto-dev | 23:15 |
| fray | https://github.com/OpenAMP/meta-openamp/tree/master/recipes-openamp/libmetal | 23:16 |
| fray | You'll see there is a libmetal_version.bb and a libmetal-dev_git.bb | 23:16 |
| fray | By default you build "libmetal" and get libmetal_version.bb. If you try to run libmetal-dev you will get an error the recipe is not available.. | 23:16 |
| fray | if you set PREFERRED_PROVIDER_libmetal = "libmetal-dev" and then build either libmetal or libmetal-dev you will get libmetal-dev | 23:16 |
| fray | the common libmetal.inc is where the 'magic' is.... | 23:17 |
| Jin^eLD | right, but I do not yet see the connection to the problem I am trying to solve...? or am I missing it | 23:17 |
| fray | note though in libmetal-dev_git.bb, the SRCREV setting.. that is important as well, it prevents even disabled items from triggering AUTOREV | 23:17 |
| Jin^eLD | basically here you decide if you are preferring the pinned or the AUTOREV version | 23:17 |
| fray | Maybe I misunderstood your issue.. | 23:17 |
| fray | We wanted to EITHER use a pinned version or AUTOREV... but if we pinned, we never wanted AUTOREV to show up or it would cause off-line build issues | 23:18 |
| fray | this allows the PREFERRED_VERSION to select the pinned or autorev explicitly.. and solves the second issue as well | 23:18 |
| Jin^eLD | OK, I get it, but that is not the problem I am facing | 23:18 |
| fray | ok, sorry I misunderstood then | 23:19 |
| Jin^eLD | my issue is that I can only build A (no matter if its pinned or autoreved) if I checked out "B" which has to be autorev | 23:19 |
| Jin^eLD | because "B" provides some login crap which A needs to fetch npm dependencies from | 23:19 |
| fray | What is your DEPENDS set to? | 23:20 |
| fray | B: DEPENDS = "A" ? | 23:20 |
| Jin^eLD | other way around | 23:20 |
| Jin^eLD | A: DEPENDS = "B" | 23:20 |
| Jin^eLD | because you can't build A without B, but you only need B if A has changed | 23:21 |
| fray | A depends on B, but you only want B if you are going to rebuild A? | 23:21 |
| Jin^eLD | yes, exactly! | 23:22 |
| fray | AFAIK there is no way to do that. Each recipe is independent of the others. If B is autorev, then the only way for A to know (depends) that B has or has not changed is to query upstream for the rev and hope the resulting hash is the same | 23:22 |
| *** cmhe <cmhe!~cmhe@dslb-088-077-007-107.088.077.pools.vodafone-ip.de> has quit IRC (Ping timeout: 256 seconds) | 23:23 | |
| Jin^eLD | no, no, wait | 23:23 |
| Jin^eLD | A does not need to know if B has changed | 23:23 |
| Jin^eLD | A needs to know if A has changed and add B as its DEPENDS only if A did indeed change | 23:23 |
| fray | If A depends on B, then it does have to know if B has changed... | 23:23 |
| *** kscherer <kscherer!~kscherer@bras-base-otwaon1146w-grc-19-184-147-77-157.dsl.bell.ca> has quit IRC (Quit: Konversation terminated!) | 23:24 | |
| fray | The dependency system doesn't know if a change to B will change A or not. So depends initiates a "cehck if B changed, if B changed then A changes" behavior | 23:24 |
| Jin^eLD | but it does so only if A says DEPENDS = "B", right? | 23:24 |
| fray | It might be possible to use hash-exclusions on a to disable that behavior... MAYBE something like: | 23:24 |
| Jin^eLD | basically, A uses some output from B and B changes often, A changes seldom and builds for a long time | 23:25 |
| fray | (in A) DEPEND_ON_B = "B" DEPENDS += "${DEPEND_ON_B}" DEPENDS[vardepsexclude] += "DEPEND_ON_B" | 23:26 |
| Jin^eLD | but A only needs to be rebuilt if A changes, it does not care about the interim changes in b | 23:26 |
| fray | that is going to say.. A depends on B.. but the hash of A is not dependency upon B.. (maybe) | 23:26 |
| fray | not sure that will work, as the task hash brings in depdnencies automatically and I don't know if that will actually exclude the dependencies | 23:26 |
| Jin^eLD | what effect would that have? | 23:26 |
| Jin^eLD | h | 23:27 |
| Jin^eLD | h | 23:27 |
| Jin^eLD | "hm" is what I wanted to write :) | 23:27 |
| fray | simple case, ignoring dependencies | 23:27 |
| fray | recipe has: | 23:27 |
| fray | A = 1 B = 2 C = 3 | 23:27 |
| Jin^eLD | but if I decide to rebuild "A" because of changes in "A", will it _then_ also rebuild "B"? | 23:27 |
| fray | that results in a recipe dependency of 0xABCD | 23:27 |
| fray | if you change A to be = 2.. then the recipe hash (not dependency) could become 0xBCDE | 23:27 |
| fray | system says BCDE isn't the same as ABCD so it needs to build | 23:28 |
| fray | with vardepsexclude you can do something like: | 23:28 |
| fray | A_PRIME = '1' A = '${A_PRIME}' A[vardepsexclude] = 'A_PRIME' B = 2 C = 3 | 23:28 |
| fray | the hash will change if A, B or C change.. but NOT if A_PRIME changes | 23:28 |
| Jin^eLD | let me try that | 23:29 |
| fray | extending this into dependencies is where I don't know what happens. I know know if vardepexcluding a DEPENDS component will change the dependeny hashes | 23:29 |
| Jin^eLD | but, just thinking back of my original idea... is there a way/event in "A" to know that "A" now needs to be rebuilt, because the fetcher detected a commit in A's SRC_URI? | 23:30 |
| fray | but in the normal case, if you declare B is needed for A to build, then if B changes the hash of A changes | 23:30 |
| fray | I don't know. You can assume though if a do_build runs it has to be built (there may be other tasks). but tasks of A can NOT affect behavior of B.. only the _OUTPUT_ of the build of one recipe can affect another (through the sysroot) | 23:31 |
| Jin^eLD | but for do_build it would be too late to inject "B" ass a dependency... | 23:32 |
| Jin^eLD | I would want to intercept that earlier and then say "OK, depdency of A:do_build is B | 23:32 |
| Jin^eLD | or something like that | 23:32 |
| fray | correct | 23:32 |
| fray | Anytime AFTER parse is too late | 23:32 |
| fray | and any event saying "I'm going to build this" will be after parse | 23:33 |
| fray | with two distinct recipes, I don't think there is anyway to do what you want without someone convincing the system to ignore hash values you would normally inherit on B.. | 23:33 |
| Jin^eLD | trying your vardepsexclude suggestion now... | 23:34 |
| fray | if you ever use bitbake-diffsigs, often it will tell you package you depend on changed which is why YOUR recipe changed.. that is the only way to break this.. remove that dependency and I'm not sure there is a way to do it | 23:34 |
| fray | I knwo vardepsexclude works WITHIN a recipe, just not sure beyond that scope | 23:34 |
| Jin^eLD | well, if it was one recipe - I can not have two git SRC_URIs I think and I also can not ignore changes in a submodule if B was a submodule? or can I? | 23:34 |
| fray | yes you can | 23:35 |
| Jin^eLD | I do? how? | 23:35 |
| fray | easy to have multiple git.... | 23:35 |
| Jin^eLD | just two space separated git lines? | 23:36 |
| Jin^eLD | where does it end up then, I mean in ${S} terms? | 23:36 |
| fray | finding an example | 23:36 |
| Jin^eLD | question is if that would help me at all though? | 23:37 |
| *** RobertBerger <RobertBerger!~rber|res@62-46-91-193.adsl.highway.telekom.at> has quit IRC (Remote host closed the connection) | 23:37 | |
| Jin^eLD | because then I would somehow need a way to say "fetch git uri 2 only if git uri 1 changes" | 23:37 |
| *** RobertBerger <RobertBerger!~rber|res@62-46-91-193.adsl.highway.telekom.at> has joined #oe | 23:38 | |
| fray | SRC_URI = "git://github.com/Xilinx/linux-xlnx.git;protocol=https;name=machine \\n git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=yocto-kmeta" | 23:38 |
| fray | that downloads two different ones. The destsuffix is the name of the directory it's placed into | 23:39 |
| fray | the 'name' is how the component is referred to.. | 23:39 |
| fray | so instead of SRCREV it becomes SRCREV_machine = "..." and SRCREV_kmeta = "..." (ignore 'type', that isn't relevant here) | 23:39 |
| Jin^eLD | ok, let me think | 23:39 |
| fray | so the 'machine' goes into the 'git' directory (default), while kmeta goes into 'yocto-kmeta' (bothin the WORKDIR) | 23:40 |
| Jin^eLD | right | 23:40 |
| Jin^eLD | but I am still thinking of how that would help me now | 23:40 |
| Jin^eLD | I have a "leading" tree and a "subtree" (the same A and B analogy) and I want to rebuild the whole recipe only if the leading tree changes, but not if the subtree changes | 23:41 |
| fray | at least in a single recipe.. then you can probably use the vardepsexclude or something else to exclude checking the second (B) item | 23:42 |
| Jin^eLD | but if I exclude checking the B item, will it rebuild B if it builds A? or will it always ignore B? | 23:42 |
| Jin^eLD | because once I see "OK, I need to build A", then I want the HEAD (AUTOREV) of B | 23:43 |
| fray | there is probably a way to say only use SRCREV_A not SRCREV_B for hashing.. but I'm not sure what it is | 23:43 |
| fray | AUTOREV is a do it or don't prospect.. thats why I always tell people not to use AUTOREV... I'm really not sure if this can help | 23:44 |
| Jin^eLD | I am testing your original vadepsexclude via DEPENDS solution now, lets see if that actually solves it | 23:45 |
| Jin^eLD | ok so first part looks good, when I build "A" it rebuilds B if there are changes in B, | 23:51 |
| Jin^eLD | now lets see how it copes with changes in A and then with changes in A and in B, but I think that first part was actually what I wanted | 23:52 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!