Can external xed or musl be used?

[alethkit]

Wondering if any edits have been performed to the vendored libraries such that there is a hard requirement for vendoring and building everything from makefiles.

in particular, intel XED seems like a nightmare to try to get to work with another build system.

[stephenrkell]

Not sure I understand the question, but at a guess, are you asking why not rely on the host environment's packaging system to install these?

Historically, I have wanted to build a local submoduled musl for two reasons. Firstly, I want to ensure I use a known-working version of musl, since we do some quite hairy stuff to initialize it in what I assume to be an unsupported way (see example/trace-syscalls.c, which calls __init_libc()) and hack its TLS code so as not to clobber the host environment's TLS (see example/fake-tls.c and the comment about __init_tp() in example/trace-syscalls.c). Secondly, we need a libc archive containing position-independent code and historically, packagers have not always included this in their distribution. That is probably less true now.

In xed's case, I don't believe xed it is in the Debian archive although I await correction. But also, why do you want xed to work with another build system? Why not just delegate to its build system? Ultimately, each codebase may have a different build system. When we vendor it, we just have to let it build the way it is written... my take is that build-script code is still code, and we should not aspire to rewrite it unless strictly necessary.