Guest9464 has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
Guest8686 has joined #yosys
Guest8686 has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
Guest3889 has joined #yosys
Guest3889 has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
V has quit [Remote host closed the connection]
V has joined #yosys
derekn has quit [Ping timeout: 244 seconds]
derekn has joined #yosys
so-offish has quit [Read error: Connection reset by peer]
so-offish has joined #yosys
<cr1901>
Is build chipdbs as a separate CMake project now unsupported after refactors?
<cr1901>
(nextpnr)
whitequark[cis]1 has joined #yosys
<whitequark[cis]1>
not yet, but once the part 2 is merged, yes
<whitequark[cis]1>
the possibility could be reintroduced, but it wasn't even clear to me that anyone is using that
<whitequark[cis]1>
i think if you do an EXTERNAL_CHIPDBS=ON build you can already have it
<whitequark[cis]1>
oh, hm, that wouldn't quite work out dependency-wise... yeah, it'd have to be added back
<cr1901>
It already doesn't work (Python3_Executable doesn't get passed down to the chipdb subproject), and I was using separate chipdbs as part of my build scripts
<whitequark[cis]1>
oh, I see
<whitequark[cis]1>
it wasn't meant to break but things like this are inevitable when refactoring a build system with many configurations that are untested on CI
<whitequark[cis]1>
why do you do that?
<whitequark[cis]1>
i added it because the Raspberry Pi i was using couldn't cope with libtrellis bba eport
<whitequark[cis]1>
s/eport/export/
<cr1901>
Yes, that's why I do it
<cr1901>
I build the chipdbs on an x64 machine, rsync them to an ARM SBC and then continue to build nextpnr on the ARM SBC
<whitequark[cis]1>
right
<whitequark[cis]1>
that PR is already big enough and frustrating enough to deal with i don't want to add split chipdb build immediately
<cr1901>
At least on Linux there's a workaround- chmod 755 ice40/chipdb.py
<whitequark[cis]1>
oh, I see
<cr1901>
(trellis_import already has the exe bit set, and so the lack of Python3_Executable doesn't break it)
<cr1901>
trellis_import.py exe bit is set in the git repo, to be clear
<whitequark[cis]1>
the part 2 is going to make cmakeing individual directories impossible anyway
<whitequark[cis]1>
cr1901: very stupid idea: build on host, rsync just the **/*.bba files to the target, build on the target
<whitequark[cis]1>
i think the bba files would be new enough that make just picks them up?
<whitequark[cis]1>
(or just rsync the entire thing and rm CMakeCache.txt
<whitequark[cis]1>
* rm CMakeCache.txt)
<cr1901>
Looks like in the past I've done just that. Yea, that'll work
<whitequark[cis]1>
like ... i could add special code paths for it but you're going to rsync the bba files anyway
<whitequark[cis]1>
it doesn't seem worth the effort if the outcome is basically the same
<cr1901>
The bba file compilation is still memory/power heavy; I have logic in my scripts to serialize them (2GB RAM SBC). But this board is also getting old.
<whitequark[cis]1>
oh huh, i didn't realize that
<whitequark[cis]1>
i suppose bbasm is a very straightforward program
<whitequark[cis]1>
i want to remove SERIALIZE_CHIPDBS, i think
<whitequark[cis]1>
it's causing race conditions that are really difficult to debug and it's blocking the PR from moving
<cr1901>
I don't use that functionality, since I know actually building the BBAs is a no-go on the SBC
<whitequark[cis]1>
if you're serializing these things manually anyway, i think i might as well do that?
<cr1901>
Yes, manual serialization
<whitequark[cis]1>
yeah okay, i now have a way forward here
<cr1901>
I watch the compilation, look for a crash
<whitequark[cis]1>
it could always be added back in a race-free way if someone figures out the right incantation
<whitequark[cis]1>
but cmake is killing me
<cr1901>
if there was a crash, that file becomes part of a serial compilation :P
<whitequark[cis]1>
I honestly can't bear looking at the goddamn cmakelists.txt any longer in a row
<whitequark[cis]1>
all i need is for YoWASP build to succeed since i already verified all other combinations of note
<whitequark[cis]1>
then i could finally ship apicula-himbaechel
<whitequark[cis]1>
* ship apicula-himbaechel in yowasp
<whitequark[cis]1>
i already have the code to run gowin_pack under the js python port, too
<cr1901>
I'll modify my scripts some other week, once the dust has settled on the CMake changes. I build all the FOSS toolchains once a week to prime sccache/ensure it builds in case I need to do development on any of them that week
<whitequark[cis]1>
I do think that the resulting build system should be a lot easier to understand and modify in the end, at least
<whitequark[cis]1>
to serialize stuff you could do make nextpnr-*-chipdb -j1 and that should do the trick?
<whitequark[cis]1>
(you'd have to expand the targets manually)