| *** paulsherwood has quit IRC | 04:14 | |
| *** paulsherwood has joined #buildstream | 04:21 | |
| *** tristan has quit IRC | 04:50 | |
| *** tristan has joined #buildstream | 05:13 | |
| *** jude has joined #buildstream | 07:29 | |
| *** anahuelamo has joined #buildstream | 08:29 | |
| *** jonathanmaw has joined #buildstream | 08:41 | |
| *** ssam2 has joined #buildstream | 09:05 | |
| *** tlater has joined #buildstream | 09:23 | |
| *** tristan has quit IRC | 09:31 | |
| *** tristan has joined #buildstream | 09:37 | |
| tristan | juergbi, So a couple things I wanted to raise about recursive pipelines | 10:45 |
|---|---|---|
| tristan | One of them is project options; right now I have it setup so that you can specify project options on a per-project-name basis in your user's buildstream.conf | 10:45 |
| tristan | (and also using `--option option1 value1 --option option2 value2...`) | 10:46 |
| tristan | juergbi, when an element or project can invoke an external project; the buildstream.conf becomes a bit ambiguous; do options in your local buildstream.conf override options which your project declares for building the sub-pipeline ? | 10:47 |
| tristan | it's a sticky area | 10:47 |
| tristan | The other thing which has been flipping through my mind is; there has always been two possible strategies for recursive pipelines; both of them are useful and probably relevant | 10:48 |
| tristan | One thing which would be interesting; is to have the project.conf define "ports" for a given project we depend on, and have one or more elements in that project refer to the project defined "port" | 10:49 |
| tristan | That allows the kind of blending of two projects while asserting that the version and options for every dependency are the same | 10:50 |
| tristan | The other approach is of course, that you are allowed to import the same project more than once with different versions and different options (imagine trying to build an OS with pre-installed flatpak runtime for instance) | 10:51 |
| tristan | I think the use cases for the second approach are less pressing, though | 10:51 |
| tristan | (and can be simulated with intermediate deployments in the meantime anyway) | 10:52 |
| tristan | And finally... I think the word "junction" is an interesting one :D | 10:52 |
| juergbi | yes, i was/am thinking about these two variants as well | 10:54 |
| juergbi | regarding options, it may make sense to explicitly forward them | 10:55 |
| juergbi | i.e., a bit like a nested script | 10:55 |
| tristan | I feel like its dangerous to let userconfig effect nested projects yeah | 10:55 |
| juergbi | especially for the second/import approach | 10:55 |
| tristan | I mean, it's of course possible to design your project, so that options control what options your project asks for on another project | 10:56 |
| juergbi | for the first one, not sure what makesa more sense | 10:56 |
| tristan | for the second one, it becomes even more ambiguous indeed | 10:56 |
| juergbi | it looks like i might not have time to sort this out until beginning of next week | 10:57 |
| tristan | what happens next week ? | 10:57 |
| ssam2 | fwiw, the way Meson deals with options for subprojects is that each option in the subproject gains a prefix | 11:01 |
| ssam2 | e.g. if I embed tracker as a subproject, all its options are available as 'tracker:enable-docs', 'tracker:libdir' etc. | 11:01 |
| ssam2 | that way they are separated from the parent project, but still controllable if need be | 11:02 |
| tristan | ssam2, that makes sense indeed, and I suppose you can just split it and keep growing | 11:02 |
| tristan | ssam2, I think that it's something that we can live without and rest in the knowledge we could do that later :) | 11:02 |
| bochecha | tristan: if it helps, for recursive pipelines, my use-case is pretty much something like Flatpak's separation into sdk/apps: I'd like that when building the apps bst get the sdk from the shared cache artifacts where the sdk build was pushed (to avoid an export/import dance) | 11:03 |
| bochecha | that's pretty much all I care about :) | 11:03 |
| tristan | bochecha, yes that's the idea :) | 11:03 |
| bochecha | oh, and being able to say "the app depends on this specific revision of the sdk", requiring an explicit `bst track` to move to a newer build of the sdk | 11:03 |
| tristan | We'll want to model the flatpak base runtime, freedesktop runtime and gnome runtime in that way too | 11:03 |
| tristan | Yeah, that is a good point; if we have "ports" defined in the project itself, `bst track` can be tricky | 11:04 |
| bochecha | what do you call "ports" ? | 11:05 |
| tristan | bochecha, I was just referring to the idea above, it's not a "thing" yet :) | 11:05 |
| bochecha | ah, so a "port" would be an external module defined in project.conf, but there wouldn't be an element for it? just elements depending on it? | 11:06 |
| tristan | I was thinking a special element that cooperates with a project-wide "port" for the sake of ensuring the same version & options | 11:07 |
| tristan | of any element that depends on those | 11:07 |
| tristan | As soon as two elements are, lets say "junctions" to another project, but refer to a different version or options; the pipeline doesnt really make sense anymore | 11:07 |
| tristan | Unless we're dealing really with just exports of built data | 11:08 |
| tristan | One way to work this might be to have a "junction" element which is project exclusive (i.e. an invariant that there can only be one for a given project name in a given resolved pipeline) | 11:09 |
| tristan | Another option would be to support `bst track` rewriting project.conf, and declaring Sources and options in a "port" in project.conf | 11:10 |
| tristan | which is actually probably not that difficult | 11:10 |
| tristan | (except that dispatched 'track' jobs are tightly coupled to elements) | 11:11 |
| bochecha | yeah, `bst track element.bst` will normally only rewrite element.bst | 11:12 |
| bochecha | (unless with --deps=all of course) | 11:12 |
| bochecha | if I defined a "port: foobar" in project.conf, would I `bst track foobar`? would `bst track --deps=all myapp.bst` also rewrite project.conf? it might be a little surprising? (or maybe I'm just overthinking this :P) | 11:13 |
| tristan | yeah but I rather mean; all tasks in buildstream are coupled with elements (when we do --deps=all, we dispatch more jobs) | 11:13 |
| tristan | that's just internals anyway | 11:14 |
| tristan | surely there is a way, with a little shifting of things around | 11:14 |
| tristan | Oh also that is a good point | 11:14 |
| tristan | there is no UX for even asking for it haha | 11:14 |
| gitlab-br-bot | buildstream: issue #103 ("Provide documentation to create a project from scratch") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/103 | 11:17 |
| gitlab-br-bot | push on buildstream@options-refactor (by Tristan Van Berkom): 10 commits (last: _options: Initial iteration of OptionPool and friends) https://gitlab.com/BuildStream/buildstream/commit/29079357fda0670f3a38a40c2e4bb5ecade3a357 | 12:06 |
| gitlab-br-bot | buildstream: issue #104 ("Rework loader and source tests") changed state ("opened") https://gitlab.com/BuildStream/buildstream/issues/104 | 12:16 |
| * tristan starting to find I think a decent pattern for using labels in gitlab bug tracking | 12:19 | |
| tristan | I've just changed the colors a bit and added a couple more labels - the dark solid colors are prioritized as in Blocker, Bug, Enhancement etc... and the lighter colored labels are not prioritized (and always show up after prioritized ones), and describe the nature of the issue (tests, documentation, frontend, etc) | 12:20 |
| tristan | Oh strange, seems prioritized and non prioritized dont show up in specific order (but not too bad) | 12:23 |
| * tristan wonders if it would make sense to add resolution labels | 12:25 | |
| tristan | Fixed, Wontfix, Invalid, Duplicate, etc | 12:25 |
| paulsherwood | +1 | 12:25 |
| tristan | its something I find useful in bugzilla yeah | 12:26 |
| gitlab-br-bot | push on buildstream@non-sandbox-builds (by Tristan Maat): 1 commit (last: Add tests for %{script} format) https://gitlab.com/BuildStream/buildstream/commit/36c575eef364d664dcecd435be2262ae2212afec | 13:03 |
| gitlab-br-bot | buildstream: merge request (non-sandbox-builds->master: Add %{script} format to `buildstream show`) #102 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/102 | 13:06 |
| gitlab-br-bot | push on buildstream@non-sandbox-builds (by Tristan Maat): 1 commit (last: Add tests for %{script} format) https://gitlab.com/BuildStream/buildstream/commit/aa29a47d6c863f275c50acc653d190943301d00b | 13:22 |
| gitlab-br-bot | buildstream: merge request (non-sandbox-builds->master: Add %{script} format to `buildstream show`) #102 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/102 | 13:24 |
| gitlab-br-bot | push on buildstream@non-sandbox-builds (by Tristan Maat): 1 commit (last: Add tests for %{script} format) https://gitlab.com/BuildStream/buildstream/commit/e070dfe9ac0e9a8ead0b31694c7ad726144dc1b0 | 13:35 |
| gitlab-br-bot | buildstream: merge request (non-sandbox-builds->master: Add %{script} format to `buildstream show`) #102 changed state ("opened"): https://gitlab.com/BuildStream/buildstream/merge_requests/102 | 13:37 |
| *** tristan has quit IRC | 14:22 | |
| *** tristan has joined #buildstream | 14:44 | |
| *** semanticdesign has joined #buildstream | 14:53 | |
| *** adds68 has quit IRC | 14:57 | |
| *** jude has quit IRC | 15:00 | |
| *** jonathanmaw has quit IRC | 16:44 | |
| *** tlater has quit IRC | 17:00 | |
| *** ssam2 has quit IRC | 17:12 | |
| *** anahuelamo has quit IRC | 18:25 | |
| *** semanticdesign has quit IRC | 21:49 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!