strobo has quit [Read error: Connection reset by peer]
strobo has joined #yosys
FabM has joined #yosys
citypw has quit [Ping timeout: 246 seconds]
notgull has quit [Ping timeout: 240 seconds]
notgull has joined #yosys
citypw has joined #yosys
schaeg has joined #yosys
kristianpaul has joined #yosys
unkraut has joined #yosys
schaeg has quit [Ping timeout: 240 seconds]
marex has quit [Server closed connection]
marex has joined #yosys
nonchip has quit [Read error: Connection reset by peer]
nonchip has joined #yosys
lexano has joined #yosys
unkraut has quit [Remote host closed the connection]
unkraut has joined #yosys
citypw has quit [Ping timeout: 246 seconds]
<dxld>
I'm looking at packaging sby for Debian. Looking at the tags I'm wondering if the release cycle is syncronized to yosys like YosysHQ/abc is or would it make sense to run an older sby against a newer yosys (or the other way around)?
<dxld>
depending on that I may package it along with the main yosys source but then the two will always be tied to each other release wise and a build problem in one will block both etc
<jix>
dxld: they're essentially synchronized, older sby against newer yosys should mostly work but older sby against newer yosys often doesn't.
<jix>
eh, older sby against newer yosys should work but older yosys with newer sby doesn't... as in adding functionality to SBY often requires adding supporting functionality in yosys
<jix>
dxld: and as a heads-up, we plan to eventually move all python frontend tools including SBY and EQY to depend on https://github.com/YosysHQ/mau and be more structured like https://github.com/YosysHQ-GmbH/ivy (IVY depends on verific for now, so not something relevant for packaging, just the only example fully developed starting with mau) but there's no concrete timeline for this for SBY yet
<jix>
so that'd also be a move from no python native packaging to relatively modern pyproject.toml based packaging, which might be relevant
<jix>
dxld: in any case I can ping you when actual work on migrating SBY to use mau starts
whitequark[cis] has joined #yosys
<whitequark[cis]>
oh finally, will they be released on pypi too?
<jix>
would make sense if we can automate that whenever we tag a version corresponding to a yosys release
<jix>
(which is "just" an issue of someone needs to find time to figure out the details to do that for the projects that are already having a pyproject.toml)
<jix>
for EQY (which will probably be moved to mau before SBY) there would also be the question of how to handle the yosys plugins it uses, compiling them against whatever yosys-config is in path while building the python package might not be the right approach in every scenario
<jix>
I guess it could optionally support that and also support compiling and caching the plugins on-demand which would only leave the question of what to do when as default
bjork1intosh has quit [Quit: Leaving]
bjorkintosh has joined #yosys
sauce has quit [Ping timeout: 264 seconds]
sauce has joined #yosys
strobo has quit [Read error: Connection reset by peer]