Alex Sandro Queiroz e Silva wrote:
Hallo,
Christian Jaeger wrote:
Alex Sandro Queiroz e Silva wrote:
The code generator of LLVM is deployed as a library. It's a verydifferent 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 (andnow I regret that) because someone said it would be no different at all of the current system. And it would.
I really didn't mean to attack you, I simply want to know of solid reasons for creating an LLVM backend.
I'm an almost 100% linux users for 9 years now (and I have only had the issue of delivering a package to windows users once, which was a program in Visual Basic and actually required bundling of all DLL's to be running stable).
So I can't talk for anyone on such a system on what is required. I was replying on the assumption that by using PATH, LD_LIBRARY_PATH (or the Windows equivalents) and the gcc -I and -L options you can move all dependency files around at will, so what difficulty remains would be to find the dependencies (on Linux you could do it by using strace, or by including just the whole toolchain), so I guess it will be the size of the resulting package which makes you question my seriousness. I'm sure it would be worthwhile hearing about numbers or experience in this area.
If you need to package libc, then why wouldn't you need to package it also when using LLVM? (My reasoning being: if libc's interfaces (aka header files) are compatible with the header files you're providing, you don't need to include the libc binary, and if it isn't compatible with what assumptions the packaged-up system has (even if it's based on LLVM), then you'd need to include it anyway.)
Christian.