IRC logs for #openrisc Saturday, 2016-04-02

--- Log opened Sat Apr 02 00:00:02 2016
mithroI can't seem to get or1k gcc to compile - following the instructions at
mithroIt fails on newlib with "compiler can't create executables"00:53
mithroOh, I see - I cloned the newlib directory into the gcc directory01:10
wallentosystemgotyou: do you mean OpenRISC-based SoC?02:46
olofkwallento: re git checkout. Ah, so before every time you copy stuff to the build directory, you checkout the revision you want. That's pretty clever08:44
olofkWe would need to apply patches on the fly then, but that's doable08:46
olofkCould probably make it backwards-compatible by just adding some options to the git/github providers08:47
olofkNote however that the github provider isn't using git at all. It's more a special case of the url provider08:48
olofkBut all this is more of an optimization. It's still possible to just download the whole repo for every core, so I think other things should be prioritized for now08:51
olofkwallento, andrzejr: I'm starting to run out of reasons to not use providers as generators, so I'm getting ready to pull in andrzejr's patches to begin with09:39
olofkSome things need to be addressed though, but that could be done later09:40
olofk1. Need to let cores register themselves as providers, so we don't have to put everything into FuseSoC09:40
olofk2. Need to invalidate the cache, when the input files changes09:41
olofkThe second item needs to be done for the cache anyway, so it's not strictly tied to providers09:41
olofkI've been thinking before about just checksumming or checking timestamps of the input files and store that somewhere09:42
olofkThat is also something I want to do with the build tree, so we don't have to clean it out every time09:42
olofkBut it needs to be done in a smart way, so we don't just end up reimplementing make :)09:43
wallentoolofk, you actually don't need to check out the entire git to one revision09:54
wallentogit checkout <revision> -- <files> checks out only the provided files from revision09:55
wallentoas we have a given fileset that should be okay09:55
wallentowe can then apply patches in tree and mv09:55
wallentomoving ensures we can reuse the same repo for other cores if necessary09:56
wallentootherwise conflicts can happen09:56
andrzejrolofk, thank you. Generator providers felt like a hack to me initially but they work really well. IMHO they are no different from built-in support for simulators or synthesizers.13:19
andrzejrhaving user-defined plugins for fusesoc could be handy indeed. Not just for providers.13:20
olofkwallento: I like the idea. We should at least plan that for the future14:34
olofkandrzejr: Yeah, I feel the same. It's great that you came up with the idea and has tested it for a while too14:35
olofkAnd plugins is good, I agree. Just don't feel like defining API for it all right now. This needs to be pretty stable14:36
olofkandrzejr: Could you rebase your changes against FuseSoC master? I've picked some of your patches, but not all14:49
olofkahh... my work switched vpn solution to use l2tp over ipsec or something like that. What a fucking mess18:21
olofkAnyone handy with that? I gave up now18:22
--- Log closed Sun Apr 03 00:00:04 2016

Generated by 2.15.2 by Marius Gedminas - find it at!