<rqou> hey azonenberg i'm fixing "stupid build system problems" and i noticed you _still_ haven't tested the no-udev rewrite
<pie__> or at least clever
<rqou> alright, does anybody know how to actually obtain libudev?
<rqou> somehow all i can find is that somehow it's part of systemd now?
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<rqou> arrgh i f*cking hate cmake
<rqou> the library is _right there_
<rqou> you even printed that you found it
<rqou> and yet you complain that it's not found
lexano_ is now known as lexano
<azonenberg> rqou: soo re the coolrunners
<rqou> i have literally never had cmake reduce the number of problems i have
<azonenberg> They are definitely laser marked
<azonenberg> The font width is slightly different on the two
<azonenberg> between the two*
<azonenberg> One of them has flux residue on underside
<rqou> whelp
<azonenberg> There is a ground pour on the bottom that i was going to compare to the actual coolrunner bondout
<azonenberg> I suspect they're pulls at best, possible full fakes
<azonenberg> But we'll find out
<rqou> oh they're almost certainly pulls
<rqou> hence why i wanted you to try to extract bitstreams from them
<rqou> but if you suspect it's remarked, that's interesting
<rqou> ohh
<rqou> azonenberg: i bet the speed grade is remarked
<azonenberg> So the big thing i noticed is
<azonenberg> the toolpath the laser took for the xilinx "X" logo
<azonenberg> was not the same on both chips
<azonenberg> one was raster and the other was more of a swirly vector
<rqou> for the 512 or the 384?
<azonenberg> One vs the othert
<rqou> i did notice that the color of the substrate was different for 1 of the 4 chips
<azonenberg> both of the same SKU were the same pattern
<azonenberg> That was flux residue
<azonenberg> I'll take a closer look later, have to clean a bunch of my sar stuff and refill before the next call
<rqou> woo finally
<rqou> $ ldd ./iceprog/iceprog
<rqou> not a dynamic executable
<rqou> there we go
<rqou> aargh except icestorm strips CFLAGS
<pie__> whats SAR?
<pie__> rqou, pulling bitstreams is so much cooler than buying off ebay
<pie__> *buying used HDDs off ebay
<azonenberg> pie__: search and rescue
<pie__> ah
<pie__> got it
<pie__> is it bad that i thought data recovery for a second
<rqou> azonenberg: at least make an attempt to retrieve the bitstream before destroying it? :P
<rqou> woot
<rqou> $ file iceprog
<rqou> iceprog: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
<rqou> no qemu-user-static required this time
<rqou> ugh, i have to touch the "hostile takeover" project again
<rqou> aaargh pkg-config is yet another "doesn't solve any problems" tool
digshadow has quit [Ping timeout: 260 seconds]
<awygle> rqou: maybe your problems just aren't the ones it's solving?
<balrog> rqou: what's the problem you're trying to solve?
<rqou> "find my library file that i built for the target architecture"
<rqou> without me needing to go in and patch .pc files
<balrog> You need it to be architecture specific?
<balrog> Meaning you're doing multiple architectures?
<rqou> um, yeah?
<rqou> i'm trying to kill "needs a whole friggin container with qemu-user-static"
<balrog> Most people do that with custom prefixes. Or use cmake.
<rqou> cmake also adds problems rather than solving them
<rqou> and i already have a custom prefix
<balrog> I don't think pkgconfig was designed for that use case
<rqou> it actually seems to be working for arm-linux
<rqou> mingw is broken though
<balrog> I've generally found it easier to beat a cmake based workflow into submission than an autotools one
<rqou> quite possibly because mingw has its own set of gratuitous brokenness
<balrog> mingw is broken? News at 11
<rqou> i've generally found the opposite
<rqou> i hate cmake workflows
<balrog> It took me a bit to get used to them but they are generally more straightforward and flexible
<rqou> well, earlier cmake was telling me it couldn't find a library that it _printed out as found_
<rqou> which is pretty brilliant
<rqou> azonenberg: when is splash going to be done? :P
<balrog> Probably a broken custom library-find script
<rqou> somehow cmake users seem so love turning build systems into "find all your shit" systems
<rqou> which is what i specifically _don't_ want
<rqou> especially since half of the "find all your shit" systems return the wrong answer half the time
<awygle> cmake is a special kind of hell
<rqou> i don't understand why "traverse a DAG" is so hard
<rqou> for bonus points, cmake can't actually traverse a DAG
<rqou> it has to fall back on make to do that part
<awygle> somebody on the #gcc channel recently said something like "every time somebody starts a new project with make, you're a little sad, but you can't actually recommend anything better"
<awygle> i mean traversing the DAG is the easy part. surely the hard part is building it
<balrog> cmake still uses make
<balrog> (Or ninja or something else)
<rqou> exactly why it's silly
<awygle> yes yes. the sentiment was comedic rather than literal.
<awygle> several of my friends swear by scons
<rqou> i tried using waf for a project
<rqou> i hated it because despite selling itself as "just traverses a DAG, correctly" waf is very "opinionated"
<awygle> i worked with a guy at berkeley who went by waf... always wonder if he's responsible for the build system.
<rqou> i've been meaning to write a "JustADAGDammit" build system but never got around to it
<rqou> azonenberg's splash might be something like that
<balrog> I got turned away from scone because it has awful support for multiple architecture projects
<balrog> cmake does better there
<rqou> hmm, in my experience cmake is just as bad as everything else
<rqou> sure, it has an idea about "toolchains"
<rqou> and then somehow somebody will manage to hardcode in a /usr/lib anyways
<rqou> wtf my entire gui stack just crashed for some reason
<azonenberg> splash is basically a dag build system, yes
<azonenberg> plus caching and parallelism
<azonenberg> But building build dags right is hard :p
<azonenberg> almost all of the bugs i currently have / had in the past were related to incorrectly building the dag
<whitequark> awygle: *definitely* get your cats toy mechanisms
<awygle> whitequark: will do. i am now intensely curious about my old cat's behavior of fetching a mouse only 50% of the way back to me...
rk[ghost] has quit [Ping timeout: 276 seconds]
rk[ghost] has joined ##openfpga
<whitequark> yes.
<whitequark> we cooperate in catching moths.
<whitequark> i can reach the ceiling, but the cat has *far* lower reaction time
<whitequark> these goddamn moths are so fast I can't even turn my eyes quickly enough to track their movement
<whitequark> the cat though, the cat could be ground support for a guided missile
<whitequark> which, incidentally, gives me an idea
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 240 seconds]
azonenberg_work has joined ##openfpga
<azonenberg_work> rqou: so, coolrunner update
<azonenberg_work> They might actually be legit xilinx devices (though possibly upmarked)
<azonenberg_work> the ground/vccio pad layout in the middle of the die looks exactly like the real xilinx ftg256
<azonenberg_work> Speed grades marked are -6 and -10 for the 384 and 512 respectively
<azonenberg_work> The 384 is actually offered in -7, -10
<azonenberg_work> as is the 512
<azonenberg_work> one of the 512s has pieces of solder braid and dust stuck to flux on the underside
Hootch_Work has joined ##openfpga
digshadow has joined ##openfpga
<cyrozap> Fun fact: The Cypress MiniProg3 uses an FX2LP, a PSoC 1 (!), _and_ an XC3S100E (!!!).
* cyrozap has been doing some MiniProg3 RE
<cyrozap> The FX2LP seems to load its firmware automatically at boot, so the only code that needs to be uploaded is the Spartan-3E bitstream. Thankfully, it's pretty much just shoveling the binary over USB, so that's nbd.
<cyrozap> Also, the SWD protocol it uses looks pretty much the same as the one used on the KitProg ("mild shock"), so I'll probably be able to share some code with the OpenOCD KitProg driver.
<rqou> azonenberg_work: while i'm cleaning up build system stuff, please please test the no-udev PR
qu1j0t3 has quit [Ping timeout: 248 seconds]
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
indy has joined ##openfpga
<rqou> it's so weird testing cross-compiling when you have qemu-user-static installed
digshadow has quit [Ping timeout: 240 seconds]
qu1j0t3 has joined ##openfpga
<rqou> fun fact: gp4prog built for arm works under qemu-user-static while iceprog built for arm doesn't
<rqou> (er, with my no-udev PR at least)
Hootch_Work has quit [Quit: Leaving]
indy has quit [Ping timeout: 240 seconds]
indy has joined ##openfpga
indy has quit [Ping timeout: 240 seconds]
indy has joined ##openfpga
scrts has quit [Ping timeout: 248 seconds]
scrts has joined ##openfpga
pie__ has quit [Remote host closed the connection]
<jeandet> Hello I would like to try adding VHDL and later Verilog support in meson build, anyone interested?
<jeandet> The idea would be to integrate toolchains such as Vendor ones or GHDL, Icarus.. in meson and being able to create/maintain projects easily.
scrts has quit [Ping timeout: 276 seconds]
scrts has joined ##openfpga
m_w has joined ##openfpga
<pointfree> cyrozap: I used one of these https://sigrok.org/wiki/Lcsoft_Mini_Board to program PSoC 5LP's before you, et al, had implemented openocd support for the KitProg.
<pointfree> It's interesting to hear what's inside the FX2LP.
<pointfree> and yeah, it does seem to load firmware on boot https://github.com/kiml/PSOC_programmer/tree/master/config
<balrog> pointfree: it makes sense that Cypress used things from the FX2 in their later chips
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
pie_ has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
digshadow has joined ##openfpga
amclain has joined ##openfpga
<cyrozap> balrog, pointfree: To clarify, there isn't a PSoC 1 inside the FX2LP, and there isn't a PSoC 1 inside the FX2LP--they're separate chips. Also, by "load at boot", I meant it has the firmware stored internally and loads that on every boot--as opposed to loading it over USB on every boot.
<azonenberg> rqou: i'll test it when i have time, i'm kinda in the middle of stuff now
<cyrozap> jeandet: Check out FuseSoC (https://github.com/olofk/fusesoc) and Migen (https://github.com/m-labs/migen), they do something similar to what you seem to be trying to do.
digshadow has quit [Ping timeout: 248 seconds]
m_w has quit [Quit: leaving]
<jeandet> cyrozap, thank you, I already know this project, I think they implemented their own system in Python. What I propose is to use an existing build system and add FPGA related features. My goal is to also rely on meson features such as wrapdb, transparent test wrapping, use of ninja and really simple syntax(Not Turing complete).
<jeandet> The other cool stuff would be to be able to mix RTL code and SW for soc projects with the same build system.
<balrog> cyrozap: I'm aware — what I meant is that sharing design patterns in newer devices does not surprise me
m_w has joined ##openfpga
SpaceCoaster has quit [Ping timeout: 240 seconds]
SpaceCoaster has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
<jeandet> I posted this on meson ML:
<balrog> jeandet: if you don
<balrog> jeandet: if you don't mind poking your head into Verilog, you could do a full open-source iCE40 workflow
<jeandet> This a draft of what it may look like. Any comment or help are welcome!
<jeandet> balrog, Yeah but I'm French... I've never used Verilog :(
<balrog> unfortunately I'm not aware of any system that can turn VHDL into something that the existing place-and-route tools handle. There have been some attempts to add VHDL support to yosys but none have gone sufficiently far...
<balrog> I think rqou was working on one and then kinda got lost with the complexity :)
<jeandet> There is a tool that convert all the VHDL sources in one Verilog file, one of my colleague tried it, I don't know if it works well...
<balrog> a tool like that might work at the netlist level
<balrog> probably not so well at higher levels
<jeandet> Anyway in a first time, we can support fully free simulation workflow, then for implementation we have to use Vendor tools until situation gets better.
<balrog> though yosys has its own intermediary-language formats...
<balrog> what I'm saying is that if you want to try to support a fully free workflow including implementation, you could do so with yosys and arachne-pnr and icestorm
<balrog> but you'd be stuck with verilog for now
<balrog> if you have a way to generate a BLIF format technology-mapped netlist from VHDL, you could do that too
<balrog> can GHDL output BLIF? I don't know.
<jeandet> I don't know neither
<balrog> seems like the author of GHDL started working on something, though. https://github.com/tgingold/ghdlsynth-beta
<jeandet> In fact I mainly what to bring attention to standard build systems like Meson and start a basic implementation to support FPGA workflows.
pie__ has quit [Read error: Connection reset by peer]
pie_ has joined ##openfpga
<jeandet> As a GRLIB user, I kind of like their script until I have to read them and worse to edit them.
<jeandet> Their usage of Makefiles is insane
<jeandet> My feeling is that their is many aspects in common between FPGA flow and Software building. Such as dependency tracking, Unit testing and just compiling files.
digshadow has joined ##openfpga
pointfree[m] has quit [Ping timeout: 240 seconds]
enick_88 has quit [Ping timeout: 258 seconds]
<pie_> well maybe people try to make fpga flow more like software dev
<pie_> </hypothesis>
scrts has quit [Ping timeout: 240 seconds]
<jeandet> pie_, yes maybe, isn't it a good point?
scrts has joined ##openfpga
pointfree[m] has joined ##openfpga
scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
Guest47103 has joined ##openfpga
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
azonenberg_work has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
azonenberg_work has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
reportingsjr has quit [Ping timeout: 255 seconds]
reportingsjr has joined ##openfpga
<rqou> f*cking autoconf
<balrog> rqou: lol
<rqou> is it just me or are there multiple levels of autocrap brokenness?
<awygle> it's not just you
<balrog> rqou: it's not broken, it's just difficult to understand
m_w has quit [Quit: Leaving]
<balrog> like cmake just somewhat worse
<rqou> no, it's definitely broken:
<rqou> checking for wcwidth broken with unicode combining characters... configure: error: in `/home/rqou/code/fpgatools-build-system/readline-6.3':
<rqou> configure: error: cannot run test program while cross compiling
<balrog> it sounds like this specific configure script tries to run a test program
Hootch has quit [Quit: Leaving]
<balrog> which would not work so well when cross-compiling
specing has quit [Ping timeout: 240 seconds]
<rqou> i thought the whole point of autocrap is to not have this problenm
<awygle> you still have to think about it when you expect to support cross-compiling
<rqou> and i thought the whole point of autocrap is that you didn't have to think about anything
m_w has joined ##openfpga
<rqou> and now there's this other piece of autocrap amazingness where autocrap will honor --host and then the makefile won't
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
<rqou> now this piece of crap can't even correctly detect if it's cross compiling
<rqou> it thinks it isn't
<rqou> how does this even happen?
<cr1901_modern> "and i thought the whole point of autocrap is that you didn't have to think about anything" HAHAHAHAHAHAHA *sobs*
<lain> ^^^^
<rqou> gotta butcher 'em all!
<rqou> (build systems)
<jeandet> rqou, cross compiling works pretty well with Meson ;)
<rqou> um, congrats?
<rqou> is that Yet Another New Build System?
<jeandet> not that new, since something like 2014
<jeandet> compared to Make or autotool it's a kid but definitely powerful
<jeandet> It really focuses on making build easy
<cr1901_modern> If I'm doing heavy cross compiling I would nominally use SCons despite its slowness
<cr1901_modern> Or I MIGHT try CMake again
<cr1901_modern> but getting cross builds to work w/ CMake was irritating when I last did it
<rqou> scons and cmake both suck
<jeandet> CMake is powerful but its syntax and doc sucks
<rqou> i'm sick and tired of "powerful" build systems
<azonenberg> CMake works well for a single ISA/architecture etc
<cr1901_modern> Why do ppl think SCons sucks? Besides its slowness, and their inability to transition to Python 3?
<rqou> i just want "walks a DAG" and "has a mechanism to expand the DAG"
<azonenberg> it does not handle multi-architecture (simultaneously) tools
<azonenberg> For example a project containing an FPGA image plus softcore CPU firmware
<cr1901_modern> azonenberg: Well I would try Splash if you ever made it stable :)
<azonenberg> Or firmware + PC software
<rqou> every time i've used a "powerful" build system it somehow manages to return the wrong answer in a way that's super painful to fix
<jeandet> here are few presentations of Meson: http://mesonbuild.com/Videos.html
<azonenberg> it can cross compile or natively compile, but not do both well
<rqou> i hate videos, got just the slide deck?
<rqou> aaand i accidentally ran the "wipe out everything" command
<azonenberg> ?
<rqou> i'm working on a tool that i'm calling "summon-build-deps"
<rqou> the first step (unless i comment it out) is to do a rm -rf
<jeandet> section in doc about cross http://mesonbuild.com/Cross-compilation.html
<azonenberg> lol
<cr1901_modern> Can Meson be customized for compilers that don't follow the gcc or visual studio command line options?
<rqou> but at least the whole point of "summon build deps" is that i can just run it again
<cr1901_modern> E.g. throwaway example: Watcom C for my DOS stuff
<rqou> hmm that meson doc has stuff like "sizeof_wchar_t" in it
<rqou> i'm instantly very skeptical
<rqou> sounds like meson has too much "expert knowledge"
<cr1901_modern> jeandet: ^^
<jeandet> cr1901_modern, I don't know that well Meson, you should ask on their IRC
<cr1901_modern> ahhh
<jeandet> rqou, its an example, you don't have to care
<rqou> the problem is that from that example it sounds like meson is more than a "traverse a DAG" tool
<balrog> jeandet: Splash is a build system azonenberg designed himself because he annoyed with what existed :)
<balrog> I think it might predate Meson
<rqou> at this point i'm so sick of "smart" tools that i _only_ want a tool that traverses a DAG really fast
<azonenberg> balrog: splash2 does not, it's a complete rewrite that is still not where i want it
<azonenberg> rqou: splash spends most of its effort building the dag
<jn__> rqou: ninja
<balrog> azonenberg: did you write up the design somewhere?
<azonenberg> that is the hard part
<azonenberg> balrog: no point, design is still in flux - i have some docs on the wiki though
<balrog> jn__: ninja is a make replacement, not an autotools/cmake/scons replacement
<rqou> the only problem with make is that mutating the DAG is a bit _too_ hard
<rqou> (.d files)
<azonenberg> rqou: and trust me, even trying to figure out what header files a C program includes
<azonenberg> is HARD
<balrog> lol
<balrog> I know well enough
<azonenberg> IMO dependency scanning is one of the trickiest parts of a build system
<balrog> we're kinda dealing with that problem with MAME
<balrog> it's still one of the "one big .h file" type projects
<azonenberg> balrog: well i'm trying to do distributed compiles
<balrog> like <windows.h>
<azonenberg> So i can't just pull in random headers from the worker node
<azonenberg> I have to know ALL of the headers i use
<balrog> which means someone makes a change to the core header, *everything* gets rebuilt
<azonenberg> and copy them to a directory structure on the worker
<balrog> err, any of the core headers
<azonenberg> And then run the compiler on the worker with -nodefaultlib
<azonenberg> and -nostdinc
<azonenberg> Because otherwise if i don't have everything on the exact same OS version/distro etc Bad Things happen
<balrog> azonenberg: so yeah you need some way of dependency scanning
<azonenberg> Yeah, i do this
<balrog> which respects preprocessor ifs/ifdefs and #pragma once
<rqou> azonenberg: i'm telling you, abuse the hell out of mount namespaces and strace :P
<azonenberg> I'm using gcc -D
<azonenberg> Then parsing that output
<balrog> which means ifdefs must all be well-formed / defined
<azonenberg> But the output sometimes uses relative vs absolute filenames...
<azonenberg> Which leads to problems when you have the same filename in multiple places
<azonenberg> I dont yet know what is wrong
<azonenberg> But i know i have problems with the gcc version debian 9 ships compiling libjtaghal
<balrog> do you have a reduced testcase?
<azonenberg> Not yet
<azonenberg> i just upgraded one box to debian 9 and splash choked
<azonenberg> then i went away for the weekend with SAR
<balrog> I'm also wondering how well clang behaves
<balrog> ahh, right
<rqou> i've had horrible luck with clang. not because clang is bad, but because the clang "compiler driver" logic is dumb as hell
<rqou> it works fine if you manually feed it everything though (including e.g. crti/crtn)
<balrog> rqou: if you haven't used it in a while... they keep improving it
<rqou> iirc "improving" consists of "adding more weird distro hacks into the compiler driver"
scrts has quit [Ping timeout: 240 seconds]
<rqou> iirc there's no easy way to make clang "just work" with things like PetProjectRTOS or PetProjectMinixFork
<rqou> maybe this is just because i have a set of hacks that works with gcc and never figured out the analogous hacks though
<cr1901_modern> I mean, this isn't unique to clang?
<rqou> basically afaik if you build a cross-gcc it will always look in some directory nearby to where the gcc binary is located
<rqou> whereas clang tries to guess and do other "smart" things
<jeandet> here is a sample of cross build cfg file with Meson: https://github.com/jpakkane/baremetal-hi/blob/master/arm-eabi-cross_file.txt
scrts has joined ##openfpga
<rqou> aaargh and i just discovered i was using the wrong version of a library
<rqou> wtf
<rqou> why does yosys also try to run code at build time?
<rqou> oh, this is an abc problem
<rqou> typical
m_w has quit [Ping timeout: 240 seconds]
<rqou> is it just me or does abc have more warnings than usual?
m_w has joined ##openfpga
<rqou> Just ABC Things :P
<rqou> arrgh abc ignores LDFLAGS
<rqou> woot it works!
<rqou> $ file yosys yosys-abc
<rqou> yosys-abc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
<rqou> yosys: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
<azonenberg> Why are you statically linking it?
<rqou> so that there are no dependencies at all and it works on any not-insanely-ancient kernel
<azonenberg> Yeah but i meant, why not just compile on the machine you're using it on?
<azonenberg> Or ship the dependent libraries with it?
<rqou> oh this is for my "public service" nightly builds
<rqou> the old builds were only guaranteed to work on ubuntu
<azonenberg> my thought on things like this is, compile it on old debian
<azonenberg> include any libs you build in the release
<azonenberg> and it should work on anything newer :p
<rqou> or just build static?
<jn__> link statically, with musl-libc. then it should run in really ancient kernels, too :)
<rqou> that's exactly what i'm doing
<rqou> it's so weird to be able to directly run the raspi binaries though
<jn__> my little binfmt_misc: qemu is magic
<azonenberg> lolol
<rqou> wow it's so weird to see the code quality difference between yosys and abc
<rqou> abc needs to learn the meaning of "portable, cross-platform code"
<rqou> not a giant pile of stupid hacks
<rqou> like -DSIZEOF_VOID_P=4 -DSIZEOF_LONG=4 -DSIZEOF_INT=4 -DWIN32_NO_DLL -DHAVE_STRUCT_TIMESPEC
<azonenberg> lol
<azonenberg> how does my openfpga code generally compare?
<rqou> seems to have worked without any major issues
<rqou> stdint.h is magic
<rqou> oooh
<rqou> i recall clifford mentioning that one of the researchers working on abc uses like VC6 or something
<rqou> does that even have stdint.h?
<azonenberg> lol
<azonenberg> um, i dont think so
<azonenberg> VC6 is from 1998
<rqou> yeah, there's a .dsp/.dsw in the abc repo
<azonenberg> ...
<azonenberg> there is no excuse for supporting a 20-year-old toolchain in a modern project
<rqou> hey at least there's # PROP Use_MFC 0
<azonenberg> MFC, lol
<azonenberg> i did some pretty sophisticated stuff with it back in the WinXP days
<rqou> what version would this be? mfc42?
<azonenberg> yeah
* azonenberg remembers shipping a MS update that pushed out a new mfc42.dll with some of his projects
<azonenberg> And getting all confused at the manifest stuff you had to do to use new MFC when vc.net and wsxs came out
scrts has quit [Ping timeout: 276 seconds]
scrts has joined ##openfpga
<rqou> because microsoft has never successfully solved dll hell
<awygle> oh wow. i just bothered to look at the ABC readme. i am alarmed.
<rqou> alright, now i just need to fight to get tcl cross-compiled
<azonenberg> rqou: what part of yosys actually uses tcl?
<azonenberg> i dont recall ever having had to write any
<rqou> idk
<jn__> all the commands in yosys are squenced by a tcl interpreter
<rqou> oh, there's an option to run a tcl command script
<azonenberg> So even yosys is infected by tcl :p
<rqou> yeah i don't understand the obsession with tcl
<awygle> heritage
<azonenberg> Which isnt a factor with new tools
<azonenberg> why use it in a new tool?
<awygle> because everyone in your market knows it
<awygle> presumably
<awygle> or, because you know it
<rqou> hmm, the binaries i'm building cannot dlopen()
<rqou> i hope nobody had a tcl script that somehow needed to do that
<rqou> azonenberg: tcl is used for the "tcl" command
<rqou> afaict that's it :P
<rqou> aargh why is it so damn hard to nuke tcl's strtoul
scrts has quit [Ping timeout: 246 seconds]
scrts has joined ##openfpga
<rqou> woot i can cross-build yosys now
<rqou> this will save something like 2 hours off of the auto-building time
<rqou> no more "raspbian in an lxc container with qemu-user-static" required
<rqou> er, except maybe for openfpga :P
<rqou> (haven't fixed cross-builds there yet)
<balrog> rqou: lots of EDA related things seem to have had John Ousterhout as a part of them
<rqou> heh i was wondering why yosys was building so slowly and it turns out i forgot to pass it -j20
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga