09:14 <lambda> litghost: I see. weirdly enough, `conda info` shows both /usr/pkgs as well as a location in my homedir for "package cache", and `conda config --describe pkgs_dirs` says "Packages [...] are downloaded and extracted into the first writable directory", so I guess this might be a conda bug?

09:21 <lambda> I think I'll just try to figure out what this conda thing is actually *trying* to do and just do that myself, seems easier

09:57 <_whitenotifier> [xc-fasm] Xiretza opened issue #10: Add LICENSE file - https://git.io/JtYgH

11:15 <lambda> I'm starting to get an understanding of these interconnected parts - basically symbiflow-arch-defs is the thing that does all the work (together with yosys/vpr/etc), takes a correspondingly long time to build, so the stuff hosted on storage.googleapis.com mentioned in the examples readthedocs are just some prebuilt packages

11:16 <lambda> alright, I think I can create a useful package from this

12:10 <lambda> what cmake targets would generate the contents of those tarballs? none of the dependencies of all_xc7 really sound like what I want (*_demos, *_route_tests, *_tests)

12:12 <sf-slack> <acomodi> @lambda: The targets are generated in any case. You can call `make install` and the contents of the tarball will end up in the designated install directory (by default cmake sets it to `/usr/local/bin` if I recall correctly)

12:15 <sf-slack> <acomodi> @lambda: If you want a custom installation path you can change when building the environment and the cmake targets with: `make env CMAKE_FLAGS="-DCMAKE_INSTALL_PREFIX=<custom_path>"`

12:15 <lambda> so a classical cmake -> make -> make install flow isn't really intended?

12:16 <sf-slack> <kgugala> lambda: it is

12:16 <lambda> in order to create an arch package it'd be ideal if all the expensive building could be separated from copying the files to DESTDIR

12:16 <sf-slack> <kgugala> look what make env does (in the top level Makefile)

12:18 <sf-slack> <kgugala> lambda: if you run make install, the build system will build/generate only those targets that required for the package

12:19 <lambda> kgugala: yes, but afaics it's not (easily) possible to build/generate those required targets without installing them, and after that just install them without building anything

12:20 <sf-slack> <kgugala> make all should do that (I guess)

12:20 <sf-slack> <kgugala> I mean build all of them w/o installing

12:20 <sf-slack> <kgugala> and build only the required ones

12:21 <lambda> I'll try that, thanks

12:22 <lambda> is it also possible to install only the files for a specific device family (ice40/ecp5/xc)? that'd allow splitting the package into a common part and device-specific parts, so that users can only install the parts they need

12:23 <sf-slack> <kgugala> I'd have to check how those targets are ogranized

12:23 <sf-slack> <kgugala> We generate separate packages for different xc7 devices

12:24 <sf-slack> <kgugala> @acomodi probably knows more

12:24 <lambda> .github/kokoro/install.sh just iterates the directories in .../share/symbiflow/arch, which works I guess, but passing an argument to make install would be nicer

12:24 <sf-slack> <kgugala> it shouldn't be that hard to add a target for those

12:24 <sf-slack> <kgugala> unless there already isn't one

19:53 <_whitenotifier> [python-fpga-interchange] litghost opened issue #8: Need canonical storage solution to ensure binary diffablity - https://git.io/JtOsL