*** tristan has joined #buildstream | 03:40 | |
*** ChanServ sets mode: +o tristan | 03:40 | |
*** jjardon has quit IRC | 04:27 | |
*** jjardon has joined #buildstream | 04:27 | |
*** ChanServ sets mode: +o jjardon | 04:27 | |
*** jjardon has quit IRC | 04:28 | |
*** jjardon has joined #buildstream | 04:28 | |
*** ChanServ sets mode: +o jjardon | 04:28 | |
tristan | juergbi, regarding https://gitlab.com/BuildStream/buildstream/-/issues/1398, I think I can get it to work at the expense of shallow loading every junction specified in the list of overrides, and only if those are local to the project being walked | 07:10 |
---|---|---|
tristan | thus incurring an additional LoadElement() load (only at _search_for_override() time) for each override in a junction's override list, but without ever incurring an unnecessary load of a subproject | 07:11 |
juergbi | ah, if we can do it without unnecessary loading of subprojects, that sounds reasonable | 07:12 |
tristan | i.e. in this loop: https://gitlab.com/BuildStream/buildstream/-/blob/master/src/buildstream/_loader/loader.py#L491 we would try substituted locally defined links | 07:12 |
juergbi | sorry I haven't commented on it yet. I took a look yesterday but noticed I need more time to fully wrap my head around it | 07:12 |
tristan | check if its a link, and see if it's a link to the subproject we're about to load | 07:12 |
tristan | yeah it's not easy | 07:13 |
juergbi | also finally need to get to your 'replacing elements through junctions' | 07:13 |
tristan | There we do `override_path = junction.name + ":" + override_path` every time, but we could check if any of the overrides in the list for that junction, are a link to something in an already loaded project leading to the project we might be about to override | 07:15 |
tristan | its definitely a bit hairy, I have to work out how to express that and make it readable | 07:15 |
tristan | but I'm pretty sure the approach is sound in theory | 07:15 |
tristan | we have access to all the links in the loaded project, and all the override lists leading to the project, we only need to check if the overrides are links | 07:16 |
tristan | yeah, I'm ofcourse stumbling on this bug while thinking of that other ML post | 07:16 |
tristan | Maybe this will be easier if I were to build a reverse mapping of links to elements; so I could determine what possible links exist for any given element/junction | 07:19 |
tristan | Only for "used links" of course | 07:20 |
tristan | Right, that would be the approach | 07:24 |
tristan | * Add to a table of reverse mapping of link name -> element name upon loading any junction | 07:25 |
tristan | * When searching for an override, we crawl up the hierarchy of projects as usual | 07:26 |
tristan | * In this case, we always have real absolute element names (or junction names) | 07:26 |
tristan | * Before trying to get a match, we normalize the list of overrides, resolving any links, making them absolute (to our knowledge, we don't know when it crosses the boundary of a not yet loaded junction) | 07:27 |
tristan | * We compare our path of actual junction names to the normalized paths in the override list | 07:28 |
tristan | The overrides in a parent project override list can be altered by loading deeper junctions too, as further links might get resolved | 07:30 |
* tristan adds that to the issue for now | 07:30 | |
gitlab-br-bot | valentindavid opened issue #1399 (Hardlinks fuse mount has improper linking) on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/1399 | 08:22 |
*** tpollard has joined #buildstream | 08:23 | |
*** santi has joined #buildstream | 08:47 | |
*** tristan has quit IRC | 09:36 | |
*** benschubert has joined #buildstream | 10:33 | |
benschubert | if someone has time to review !2079 and ensure I didn't forget any asserts, it would be greatly appreciated! | 11:37 |
gitlab-br-bot | MR !2079: Ensure we are not calling methods with side effects on the element graph in jobs https://gitlab.com/BuildStream/buildstream/-/merge_requests/2079 | 11:37 |
*** tomaz has joined #buildstream | 13:20 | |
tomaz | how do I specify that a junction is in a subfolder from elements? this - junctions/freedesktop-sdk.bst:public-stacks/buildsystem-cmake.bst - does not seem to work. | 13:21 |
tomaz | I get a Could not find element 'freedesktop-sdk.bst' in elements directory '/data/Projects/Buildstream/kde-build-meta/elements' (without a line number of the error) | 13:21 |
tpollard | interesting, I'm not sure I've ever had a project with junctions in a subdir | 13:22 |
tpollard | maybe it's a limitation | 13:25 |
tomaz | tpollard: One thing that I'm struggling in buildstream projects in general is to discover "what" should I `bst build` to get the resulting build | 13:25 |
tomaz | many projects have just a lot of .bst files on elements, anyone of them *could* be the "main.bst" | 13:25 |
tomaz | so I'm trying to remove as much as possible from elements/ leaving there what I want to give access to the users to build | 13:26 |
tpollard | yeh I can see why you'd want that indeed | 13:26 |
tpollard | unless there's a specific reason against it, I'm sure it'd be a trivial patch | 13:27 |
tpollard | along with some tests | 13:27 |
tomaz | for this I tested something that depends only on freedesktop-sdk, moving it to another folder. | 13:27 |
tomaz | would you like to test too - and see if I did something wrong on the file perhaps? (you don't even need to build, it fails in 2 seconds) | 13:28 |
tomaz | gitlab.com/tcanabrava/kde-build-meta , branch `test_subfolders`, the element I'm trying to build is libs/kf5/tier1/extra-cmake-modules.bst | 13:30 |
coldtom | https://gitlab.com/tcanabrava/kde-build-meta/-/blob/test_subfolders/elements/libs/qt5/qtbase.bst is in the build tree which references the non-existent freedesktop-sdk.bst | 13:32 |
tomaz | aha. thanks. | 13:33 |
tomaz | coldtom: but even removing the (wrong) dependencies to it, and leaving my depends just with: | 13:34 |
tomaz | depends: | 13:34 |
tomaz | - junctions/freedesktop-sdk.bst:public-stacks/buildsystem-cmake.bst | 13:34 |
tomaz | I have the same problem. Does buildstream loads all of the .bst files instead of trying to load only the ones I specified? | 13:34 |
tomaz | (the lack of line number on the error message is bad, something like "Could not find element 'freedesktop-sdk.bst' in elements directory '/data/Projects/Buildstream/kde-build-meta/elements' specified in ElementSomething.bst` would be a great help :) | 13:35 |
coldtom | hmm aiui it should only load those which are in the build tree | 13:38 |
benschubert | It only loads the files that are required indeed | 13:39 |
benschubert | tomaz: for the missing line number, this seem like a bug to me. If you can have a small reproduction and make an issue, would help ensuring it doesn't fall through the cracks :) | 13:39 |
tomaz | benschubert: ok. | 13:39 |
tomaz | I think I have the minimum necessary for the line number bug, sec. | 13:40 |
tomaz | coldtom: I just updated my test branch with removed dependencies from extra-cmake-modules to make sure that I have a failure. | 13:40 |
*** muelli has joined #buildstream | 13:41 | |
tomaz | also, updating to bst 1.6.0 (I was on 1.5.1) | 13:41 |
muelli | hola. I was curious to learn about plans for 2.0. | 13:42 |
benschubert | muelli: hey! anything in particular in the plans? | 13:43 |
tomaz | yeah, minimal example ready (and bugged, cool). | 13:45 |
muelli | rather superficial reg. incompatibilities. We're discussing internally whether we should use a self-made wrapper (which, if you ask me, has grown out of control) around debootstrap or use something like BuildStream. The concern there was 2.0 was about to come and bring incompatibilities... | 13:47 |
benschubert | So, here is out of the top of my heads the incompatibilities between 1.X and 2.X: | 13:50 |
benschubert | - project.conf has a few different keys that need to be set | 13:50 |
benschubert | - artifacts are not compatible, if you have a cache you will need to rebuild your whole project | 13:50 |
benschubert | - plugins API has changed, we ported all the previous core plugins, and we're moving them out of the core (might not be marked as 'stable' right now) | 13:50 |
benschubert | Otherwise, the element files will have also some different configuration, but I don't think there are many changes. | 13:50 |
benschubert | if I recall correctly, the Freedesktop SDK team have a test branch with bst master, that is rebased from time to time | 13:50 |
gitlab-br-bot | tcanabrava opened issue #1400 (Missing line number on error) on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/1400 | 13:51 |
tomaz | coldtom and benschubert: my minimal project that exibits both bugs (not being able to use a junction in a subfolder, and missing line number on error) https://gitlab.com/BuildStream/buildstream/uploads/511d96becbf3275f525beba44eaa8ae0/test-junctions.tar.gz | 13:52 |
tomaz | the issue: https://gitlab.com/BuildStream/buildstream/-/issues/1400 | 13:52 |
*** jward has quit IRC | 14:34 | |
*** jward has joined #buildstream | 14:34 | |
*** jjardon has quit IRC | 14:35 | |
*** jjardon has joined #buildstream | 14:37 | |
*** ChanServ sets mode: +o jjardon | 14:37 | |
*** jjardon has quit IRC | 14:38 | |
*** jjardon has joined #buildstream | 14:38 | |
*** ChanServ sets mode: +o jjardon | 14:38 | |
*** jward has quit IRC | 14:42 | |
*** jward has joined #buildstream | 14:45 | |
*** jward has quit IRC | 14:47 | |
*** jjardon has quit IRC | 14:48 | |
*** jjardon has joined #buildstream | 14:49 | |
*** ChanServ sets mode: +o jjardon | 14:49 | |
*** jjardon has quit IRC | 14:50 | |
gitlab-br-bot | tcanabrava opened issue #1401 (Buildstream does not work with junctions in subfolder) on buildstream https://gitlab.com/BuildStream/buildstream/-/issues/1401 | 14:52 |
*** jjardon has joined #buildstream | 14:52 | |
*** ChanServ sets mode: +o jjardon | 14:52 | |
*** jjardon has quit IRC | 14:53 | |
*** jjardon has joined #buildstream | 14:53 | |
*** ChanServ sets mode: +o jjardon | 14:53 | |
*** jjardon has quit IRC | 14:54 | |
*** jjardon has joined #buildstream | 14:54 | |
*** ChanServ sets mode: +o jjardon | 14:54 | |
*** jjardon has quit IRC | 14:55 | |
*** jjardon has joined #buildstream | 14:55 | |
*** ChanServ sets mode: +o jjardon | 14:55 | |
*** jjardon has quit IRC | 14:56 | |
*** jjardon has joined #buildstream | 14:56 | |
*** ChanServ sets mode: +o jjardon | 14:56 | |
*** jjardon has quit IRC | 14:57 | |
*** jjardon has joined #buildstream | 14:58 | |
*** ChanServ sets mode: +o jjardon | 14:58 | |
*** jjardon has quit IRC | 15:05 | |
*** douglaswinship has quit IRC | 15:06 | |
*** douglaswinship has joined #buildstream | 15:06 | |
*** jjardon has joined #buildstream | 15:06 | |
*** ChanServ sets mode: +o jjardon | 15:06 | |
*** jjardon has quit IRC | 15:07 | |
*** jjardon has joined #buildstream | 15:07 | |
*** ChanServ sets mode: +o jjardon | 15:07 | |
*** tpollard has quit IRC | 16:25 | |
*** tomaz has quit IRC | 18:05 | |
*** santi has quit IRC | 18:22 | |
*** santi has joined #buildstream | 18:22 | |
*** santi has quit IRC | 18:27 | |
*** muelli has quit IRC | 19:21 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!