Hallo,
Christian Jaeger wrote:
Alex Sandro Queiroz e Silva wrote:
The code generator of LLVM is deployed as a library. It's a very
different thing to deploy a library (linked statically or as shared objecyts) and deploying a complete development environment.
In which way is it different? In every Linux system it would just be a dependency on a package, the rest is solved. In Windows or OS X it would probably a question of statically linking the libraries or bundling the libraries or binaries with your package. Why is bunding a binary more of a problem than bundling a library? (And you might have other binaries you'd want to bundle with your package anyway!)
I can't believe you are serious. It is just not bundling a binary. It is bundling a compiler, a linker, an assembler, header files (ANSI C and OS-specific), libc, linker scripts etc. Can't you see this is different than shipping just a library to a client?
It's a question of balance. Developing an llvm backend just because there is no nice script bundling up all your dependencies into one deployable blob would be energy invested in the wrong place.
I never asked for a LLVM backend for Gambit-C. I only replied (and now I regret that) because someone said it would be no different at all of the current system. And it would.