| jjardon | I was about to ask for examples and just discovered https://gitlab.com/tristanvb/buildstream-tests/tree/master :) | 00:21 |
|---|---|---|
| *** tristan has joined #buildstream | 05:27 | |
| *** ChanServ sets mode: +o tristan | 08:41 | |
| *** csoriano_____ has joined #buildstream | 10:01 | |
| *** csoriano_____ is now known as csoriano | 10:02 | |
| *** csoriano____ has joined #buildstream | 10:06 | |
| *** csoriano has quit IRC | 10:08 | |
| *** ssam2 has joined #buildstream | 10:11 | |
| *** csoriano____ is now known as csoriano | 10:20 | |
| jjardon | owen, the gjs maintainer and me spent a couple of ours yesterday trying to fix a build failure in mozjs38 in continuous; then we have to make a patch for jhbuild and now we have to fix the flatpak SDK; can we have this NOW, please? :) | 10:37 |
| tristan | jjardon, soon, I just have to get this other client stuff out of the way so I can focus on this :) | 10:41 |
| tristan | jjardon, is that arm related mozjs failure ? | 10:42 |
| tristan | i.e. mozjs builds fine, and then depending gjs packages crash when trying to detect things with gjs in configure scripts ? | 10:42 |
| tristan | (which happens only on arm afair) | 10:42 |
| jjardon | tristan: no it was a problem with mozjs creating symlinks | 11:11 |
| jjardon | so it affect all the platforms | 11:11 |
| tristan | mmm, so there is still a legitimate bug in the arm mozjs builds, I had filed a bug against gjs but found it was clearly not their problem so closed it | 11:13 |
| jjardon | tristan: oh sorry; yeah it was a problem in mozjs compilation that makes gjs to fail to compile | 11:15 |
| jjardon | one sec | 11:16 |
| tristan | thats not the same one then | 11:16 |
| tristan | gjs compiles just fine on arm, even though the mozjs interpretor does not work (yeah, how that happened I cant tell) | 11:17 |
| jjardon | tristan: http://build.gnome.org/continuous/buildmaster/builds/2017/02/16/58/build/log-gjs.txt | 11:17 |
| tristan | it's when another component uses a configure macro to invoke gjs, to find out if a dependency exists, that component fails (cause the interpretor is *finally* invoked) | 11:17 |
| jjardon | fix : https://git.gnome.org/browse/gnome-continuous/commit/?id=017520b70ff8c0cbdc65eb5a5930ca51e5a9d70b | 11:17 |
| tristan | jjardon, I presume you will take care of curing the flatpak builds of the same illness ? | 11:18 |
| tristan | we'll see if that makes any difference | 11:19 |
| jjardon | tristan: I used to fix things in one place (jhbuild), now we have to do it in 3 different place, so time is limited :/ | 11:25 |
| * jjardon didnt have time yet to assimilate how changes in the GNOME flatpaks can be tested and pushed | 11:25 | |
| tristan | jjardon, the builders just build what is latest, so there is no pre-merge CI if that's what you mean | 11:28 |
| ironfoot | tristan: can different variants of a .bst file be used in the same pipeline? | 11:41 |
| ironfoot | or there is just one variant type that can be used | 11:41 |
| ironfoot | ...per build | 11:41 |
| tristan | ironfoot, one per build | 11:47 |
| tristan | you only build one target at a time, indeed | 11:47 |
| tristan | ironfoot, of course that means that there can be many active variants, but one build graph will be resolved with the chosen variants | 11:49 |
| tristan | to try to be more clear, but possibly fail in doing that :) | 11:49 |
| tristan | so yeah a bst project may declare many variants, but only one variant of each chosen dependency will be chosen to form the build graph that we build | 11:50 |
| ironfoot | right | 11:59 |
| ironfoot | so in the case of looking for dependencies loops, I can ignore the variants, and just look at the files loaded | 12:00 |
| tristan | The circular dependency check was originally inside variant resolution | 12:12 |
| tristan | I think i moved it out after finishing with variant resolution | 12:12 |
| tristan | So I think variant resolution is circular reference safe (wont spin) | 12:12 |
| tristan | ironfoot, you are embarking on the most tricky part of the code base, code-wise | 12:13 |
| tristan | just a warning :) | 12:13 |
| ironfoot | this is how you learn, and get invovled :) | 12:17 |
| tristan | nod | 12:21 |
| tristan | I wanted to fix that but hands tied :-/ | 12:21 |
| tristan | As I mentioned above, a recursive list accumulation-checking method should work | 12:22 |
| tristan | (so long as each recursion has a new copy of the list) | 12:22 |
| tristan | should be 0(n) this way but cost a lot of memory | 12:22 |
| tristan | I think | 12:22 |
| ironfoot | that matches my thoughts | 12:23 |
| ssam2 | but as long as the memory is freed again, it'll prepare the user for the upcoming C++ compiles :-) | 12:24 |
| tristan | hah | 12:25 |
| *** csoriano has quit IRC | 12:27 | |
| tristan | ironfoot, can be done in one list even | 12:27 |
| tristan | o if self in list then raise LoadError() | 12:28 |
| tristan | o add self to list | 12:28 |
| tristan | o recurse dependencies | 12:28 |
| tristan | o remove self from list | 12:28 |
| tristan | ? | 12:28 |
| *** csoriano has joined #buildstream | 12:29 | |
| *** csoriano has quit IRC | 12:33 | |
| ironfoot | i think i have already implemented it :) | 12:34 |
| ironfoot | but will need reviewing, ofc | 12:34 |
| tristan | does ./setup.py test pass ? | 12:34 |
| *** csoriano has joined #buildstream | 12:35 | |
| *** csoriano has quit IRC | 12:45 | |
| ironfoot | i dont know, given that they don't work in my setup | 12:45 |
| ironfoot | will have a look at it before sending the patch | 12:46 |
| tristan | ironfoot, iirc only the sandbox tests fail for you ? | 12:48 |
| tristan | ironfoot, if everything else passes, you should be good | 12:48 |
| tristan | particularly: tests/loader/dependencies.py::test_circular_dependency PASSED | 12:49 |
| *** csoriano has joined #buildstream | 12:50 | |
| ironfoot | that one passes | 13:06 |
| ironfoot | but am worried about "buildstream/_loader.py FAILED" | 13:07 |
| tristan | hmm | 13:10 |
| tristan | does it come with any other context than that ? | 13:10 |
| * tristan lets ironfoot fiddle | 13:10 | |
| ironfoot | yep, I'll get to it | 13:10 |
| ironfoot | ah, my little friend pep8 | 13:11 |
| tristan | ah, that's easy :) | 13:12 |
| tristan | ironfoot, that should not work | 13:28 |
| tristan | ironfoot, seems to just reveal that my circular dependency check is broken | 13:29 |
| tristan | I mean s/check/test case | 13:29 |
| tristan | and s/broken/not complete enough | 13:29 |
| tristan | or does it | 13:29 |
| tristan | aha hmmm | 13:29 |
| ironfoot | I'm the one learning here :) | 13:30 |
| tristan | I'm still a bit unsure :-/ | 13:30 |
| tristan | variants make this more tricky | 13:30 |
| ironfoot | I thought: file being loaded twice, kaboom | 13:30 |
| ironfoot | and then i thought: variants? | 13:30 |
| ironfoot | but same thing for variants, given that one variant per build | 13:30 |
| tristan | Well, that's what the following line "if filename in self.loaded_files" is for | 13:31 |
| tristan | ironfoot, right, which led me to think, after resolving variants, when we have a realized dependency graph, that list check would be safe (so long as variant resolution doesnt possibly spin) | 13:31 |
| ironfoot | that is so that if 2 things depend on, say, core, you don't compute core twice | 13:31 |
| tristan | ironfoot, the thing to remember is that, a chosen variant dictates the final dependencies of that element | 13:32 |
| tristan | So, it's possible that in one variant, foo depends on bar, and in another bar depends on foo | 13:33 |
| ironfoot | interesting | 13:33 |
| ironfoot | that case should be added to the test | 13:33 |
| tristan | indeed | 13:33 |
| ironfoot | (if possible, haven't looked at the tests yet) | 13:33 |
| tristan | well, this approach requires a bit of thought | 13:42 |
| tristan | it's a hard problem :-/ | 13:43 |
| tristan | When resolving the conflict inside variant resolution (which I suppose could be accomplished with the same approach), it would result in raising a circular dependency error "for a given variant branch" | 13:44 |
| tristan | which is questionable | 13:44 |
| tristan | because we dont know yet, if that branch is suitable to choose | 13:44 |
| tristan | if we do it at file load time, we're not even sure if it's a dependency | 13:45 |
| tristan | the best would be if we could do it post-variant-resolution, while ensuring that variant resolution cant spin | 13:45 |
| tristan | I guess | 13:46 |
| tristan | but that is a guess, not law :) | 13:46 |
| *** leeming has joined #buildstream | 14:07 | |
| tristan | ironfoot, in any case, with this approach you are able to resolve the converted baserock ? | 14:20 |
| tristan | I will look further into this, if there is an approach of checking circ-deps *after* variants I will try to find that | 14:20 |
| tristan | ironfoot, the script afaics (I tried the repo this morning) still encodes dependencies as "type: build", which will mean it wont build or work | 14:21 |
| tristan | looks like the depends was corrected only in stacks, but not in the other elements | 14:22 |
| ironfoot | sure, the defs2bst script is not finished. I'm dealing now with some little details, but at least i can get BuildStream to complain | 14:23 |
| ironfoot | I haven't thought about the dependencies yet | 14:23 |
| * tristan notes that as an improvement, build-essential.bst could be split into one which contains tools and another with only the runtime | 14:23 | |
| tristan | and core.morph could normal depend on the runtime part only, while build: only depending on the one with tools | 14:24 |
| tristan | causing busybox to disappear once coreutils is there :) | 14:24 |
| tristan | doesnt fall into the purview of an autoconversion | 14:25 |
| tristan | just noting | 14:25 |
| * tristan should probably do that with build-essential right away though | 14:25 | |
| *** tristan has quit IRC | 14:35 | |
| *** xjuan has joined #buildstream | 14:43 | |
| *** csoriano has quit IRC | 14:48 | |
| *** csoriano____ has joined #buildstream | 14:48 | |
| ironfoot | yay! pulling sources :) | 14:51 |
| *** tristan has joined #buildstream | 15:07 | |
| *** csoriano____ has quit IRC | 15:09 | |
| *** csoriano____ has joined #buildstream | 15:11 | |
| *** ChanServ sets mode: +o tristan | 15:12 | |
| *** csoriano____ is now known as csoriano | 15:24 | |
| ironfoot | tristan: building core.bst here :) | 15:25 |
| tristan | sweet, did you remove the build-only deps too ? | 15:29 |
| * tristan thinks it wouldnt build without that | 15:29 | |
| ironfoot | i haven't because I still don't understand the deps types | 15:31 |
| ironfoot | i know it will fail | 15:31 |
| tristan | ironfoot, for all the auto conversions, dont put any "type", just list em out as filenames | 15:35 |
| tristan | I think the first part I did was to sort out how strata / stack deps are transformed | 15:35 |
| tristan | so that part should be ok | 15:35 |
| *** csoriano has quit IRC | 15:36 | |
| tristan | ironfoot, 'build' means: I only need this to build (and needing it, implies it has to run), "run" means, I only need this to run | 15:36 |
| *** csoriano____ has joined #buildstream | 15:36 | |
| tristan | ironfoot, the default is both | 15:36 |
| ironfoot | right | 15:37 |
| *** csoriano____ is now known as coriano | 15:37 | |
| *** coriano is now known as csoriano | 15:46 | |
| *** persia has joined #buildstream | 15:48 | |
| ironfoot | I've updated my forks, (without changing the dependency type yet) | 15:49 |
| ironfoot | but it's something :) | 15:49 |
| *** ssam2 has quit IRC | 18:31 | |
| *** tiagogomes has quit IRC | 18:58 | |
| *** csoriano has quit IRC | 20:13 | |
| *** xjuan has quit IRC | 21:11 | |
| *** tristan has quit IRC | 21:34 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!