<rqou>
at some point i should go build a brute-force dependency handler powered by ptrace, mount namespaces, and fuse
<azonenberg>
There's no distinction between cross or native compilation
<azonenberg>
your build script includes a list of target triplets
<azonenberg>
and you build for those
<azonenberg>
if at least one node with each compiler can't be found it fails (unless you explicitly requested "only build the x86_64-linux-gnu targets"
<cr1901_modern>
meson does this approach to mixed success (not all C compilers understand target triplets)
<azonenberg>
cr1901_modern: no but the wrappers do
<azonenberg>
splashbuild knows how to target each triplet it advertises support for
<azonenberg>
the exact flags it passes to the compiler, and what compiler it invokes, can vary
<rqou>
wait, does splash have intimate knowledge of how the toolchains work?
<azonenberg>
It has a driver class for each compiler
<azonenberg>
as well as mappings from technology-independent "meta-flags" like "library/target/foo" to link to a target in this project called libfoo
<rqou>
i don't want that
<awygle>
This sounds like a pretty sane if possibly over built solution.
<azonenberg>
or "library/optional/bar" to link to a library named libbar which may or may not be present
<azonenberg>
(and define HAVE_BAR globally if found)
<rqou>
i've been burned so many times by build systems that think they know something about the toolchain
<azonenberg>
rqou: the solution is to actually know things about the toolchain :)
<awygle>
And honestly build is a fundamentally hard enough problem that overbuilding may be appropriate
<azonenberg>
Compilers are specified generically too
<azonenberg>
normally my C++ stuff is targeting "c++/generic"
<azonenberg>
which currently picks the highest g++ version for the target architecture supported by at least one node, but this heuristic may change (no clang support yet but that shouldnt be too hard to add later)
<azonenberg>
And if the available compilers change, because a node joined or left the cluster, this changes the hashes and you have to rebuild everything
<rqou>
i dunno, i hate build systems that are "smart"
<azonenberg>
Eventually i'll add better heuristics that say something like, don't switch to a compiler only one node has
<azonenberg>
if you have 75 cores that have a slightly older version available
<azonenberg>
In any case if you actually need an exact version of the compiler you could do something like c++/gnu/4.7
<rqou>
also, afaict there's basically no reason for me to ever build "generic"
<awygle>
Does splashbuild advertise some measure of the capability of the node (e.g. Number of threads)?
<azonenberg>
For what i'm doing i almost always build generic, and let the toolchain decide what compiler it wants for my list of architectures
<azonenberg>
awygle: It reports RAM and bogomips right now, better CPU benchmarking is on the wishlist
<azonenberg>
splashbuild-launcher spawns one instance per either hardware core or logical core, i forget
<rqou>
if i were to do builds nowadays, it would start with "use musl-cross-make (which already solved this problem for me, thanks dalias) to build an x86_64 toolchain, then use that to build everything"
<awygle>
cool
<azonenberg>
each instance does one build job at a time
<azonenberg>
When launching jobs it preferentially uses the fastest node
<azonenberg>
eventually i'll support tagging jobs (in the toolchain) as "probably needs at least 8GB RAM" etc
<azonenberg>
and the scheduler will take this into account
<rqou>
actually, hmm
<azonenberg>
anyway, this also works for FPGAs
<azonenberg>
except instead of using architecture triplets directly, i specify board description files
<azonenberg>
which contain a description of the target FPGA and speed grade, the package, available clock sources. and a list of pins with locations and io standards for each
<rqou>
if i were to do this again, i would probably manually use musl-cross-make to build an x86_64 toolchain built against glibc, use that to build an x86_64 toolchain built against musl, and then feed that into the build system as the root of the "reflections on trusting trust"
<azonenberg>
This is then converted into a UCF or XDC or whatever your target FPGA toolchain uses
<azonenberg>
Right now i support ISE UCF and openfpga PCF file formats
<rqou>
and then have the build system invoke musl-cross-make to build all the other cross compilers i need
<azonenberg>
but i plan to support XDC once i add a vivado back end
<azonenberg>
as well as whatever quartus uses
<awygle>
azonenberg: did you invent a format for board description or steal one?
<azonenberg>
I have my own yaml format that's toolchain independent
<azonenberg>
it also includes data about clock sources so you can auto-generate timing constraints
<azonenberg>
and also, (splash v0.1 supported this but 0.2 doesn't yet)
<azonenberg>
auto-generate PLL configurations
<azonenberg>
so you can say "IDGAF what the main clock source on this board is, gimme 250 MHz"
<awygle>
Are there any standards in this space? Lattice has an "lpf"...
<azonenberg>
This is explicitly designed to transcend vendors and architectures
<azonenberg>
and be converted to whatever the local format is
<azonenberg>
i already can take one verilog file and one build script
<azonenberg>
and produce binaries for spartan3, spartan6, and 7 series
<awygle>
I get that, just wondered if there's anything like e.g. vcd
<azonenberg>
with a little more work you'll be able to do gp4par, quartus, vivado, etc too
<azonenberg>
and not that i'm aware of
<awygle>
Or better yet ip-xact
<azonenberg>
anyway i have a lot more work to do
<azonenberg>
but i'd love to get somebody involved with development
<azonenberg>
(hint hint)
<awygle>
Haha
<rqou>
meh, i'd rather have a build system powered by ptrace
<awygle>
Ask me in like... February
<awygle>
Not sure how the rest of the year is full in October but... Here I am, somehow
<azonenberg>
Lol
<azonenberg>
Welcome to the club
<azonenberg>
i'm moving early next year
<azonenberg>
already starting to clean things up a bit
<awygle>
I don't even get a cool house at the end of all my stuff
<awygle>
I guess I got cats tho, they are fairly cool
<awygle>
I have to burn all my PTO in January to go on a self-generating cruise
<azonenberg>
self-generating?
* azonenberg
wonders if that has anything to do with cogeneration
<azonenberg>
:p
<qu1j0t3>
regenerating.
<qu1j0t3>
he's The Doctor.
<qu1j0t3>
(errr sorry for assuming pronoun)
<awygle>
As far as I can tell there are zero humans who want to go on this cruise
<awygle>
But it's happening anyway
digshadow has quit [Quit: Leaving.]
<cr1901_modern>
qu1j0t3: Well catching yourself is good :P
* qu1j0t3
sighs. not quite good enough
<qu1j0t3>
awygle: sounds like something i'd be taking lots of reading material to, hah
<awygle>
qu1j0t3: I'm going to bring books and a laptop and get yelled at anytime I take either out :-P