<whitequark>
marcan: i... *think* it's two weeks since you told me to ping you in two weeks?
_whitelogger has joined #glasgow
Exec1N has joined #glasgow
ExeciN has quit [Ping timeout: 240 seconds]
<electronic_eel>
Stormwind_mobile: I think there is something you could help with: packaging
<electronic_eel>
Stormwind_mobile: apart from python-based stuff, Glasgow needs yosys and nextpnr
<electronic_eel>
yosys and nextpnr need to be a fairly recent version, usually something near git head and not the latest official release from 2-3 months back
<electronic_eel>
so nearly no linux distribution carries those
<electronic_eel>
and we also want to support windows, so they have to be compiled for windows too
<electronic_eel>
WSL won't work on windows because it doesn't support usb access, so it should be native windows
<electronic_eel>
whitequark considered using WSL and writing a windows-native libusb socket proxy, but I consider this to be a whole new project of it's own
<daveshah>
I haven't tried but I think it should be
<electronic_eel>
this isn't as easy on windows as on linux, as you can't just publish a complete vm due to licensing
<daveshah>
I think it's just cross compiling using mingw
<electronic_eel>
ah, ok, that could work
<daveshah>
But I think xobs was also doing some builds with msvc
<electronic_eel>
unfortunately you currently need a Glasgow hardware connected before the software begins to build gateware
<electronic_eel>
this means you can't easily test the software stack without hardware
<electronic_eel>
you'd need to patch the software a bit to trick it into building
<electronic_eel>
oh, I remember this might not be correct, there is the test mode
<electronic_eel>
but I haven't looked into that yet
<miek>
`glasgow build` runs fine without hardware
<electronic_eel>
ok, then I remembered that part wrong. all the better, so packaging is something that could be done without hardware and that could need some help
<electronic_eel>
while this isn't glasgow-specific, it is something that makes using glasgow on windows much harder than necessary, so debugging it will help
Exec1N is now known as ExeciN
<whitequark>
daveshah: not sure the xobs toolchain will work
<whitequark>
it already has all the python stuff, which glasgow needs on its own
<daveshah>
So part of me thinks the best option is to add another way to do timing constraints (lpf constraints are already supported for ECP5)
<daveshah>
Then there is no need to bundle python with nextpnr at all
<whitequark>
yes, i would be really happy with that
<whitequark>
using python literally so that i could call one method is suboptimal
<daveshah>
Indeed
XgF has quit [Remote host closed the connection]
XgF has joined #glasgow
<marcan>
whitequark: so I still don't have a reasonable workstation, but I'm *almost* there
<marcan>
I'm going to spend what's left of today/tomorrow making shit acceptable