| > Effort in this direction would be better spent just adding new features to clang (or GCC). In your opinion. This isn't a fact. For example, I know first hand of code that has to compile with compilers that are not in the set { gcc, clang, msvc }. What do I do then? (Oh, and those compilers are closed-source). > You'll end up wanting to just use clang's front end to help you Probably, although there are other options too > and at that point why not just modify clang itself? The changes I make, if useful to the community, would probably end up back in clang. But they would also remain a separate tool, because of all those other pesky compilers I work with. > you can always revive the LLVM C backend I'm not sure how that helps me; not only does it seem a terribly roundabout way to get what I'm looking for (instead of sugar -> c++ -> my c++ compiler, you are proposing sugar -> clang -> llvm -> c -> my c compiler), but I don't think objects produced by that pipeline would link with C++ objects produced from my native compilers, among other issues. > The fact that nobody has bothered to revive it and keep it up to date enough to be merged into LLVM proper, to me, is a strong indication that few people need support for these obscure platforms. Or, is it evidence that people using more obscure platforms (we're talking fortune 500 companies here) stick to languages that exist on their platforms for various reasons? |