Stallman on GCC, LLVM, and copyleft

that's about the only statement you got right ;).

> Please avoid the ad hominems.

not before you learn to follow your own advice.

> Yes I said stable APIs are the back-bone of successful open projects, and I mean it.

so according to you linux and gcc are not successful.

> Linux has a rock stable API

wrong. the kernel's API has nothing to do with the syscall interface it provides to userland. the former is for kernel code, modules included, not userland and is intentionally not stable.

> Breaking backwards compatibility is typically seen as a bug.

linux does it all the time. please submit your bugreport to lkml. we all need a good laugh every now and then after all ;).

> When it comes to linux drivers, we are not talking about an API, but about an ABI.

wrong. you don't have a clue what these words mean, do you ;).

> It is somewhat different,

they're not somewhat different, but very different things. they refer to different levels of abstraction.

> but as I said, there is not supposed to be an API for external use there.

this sentence makes no sense whatsoever.

> People are expected to include the drivers as part of the distribution.

what does being in-tree vs. out-of-tree even have to do with the kernel API?

> This is different.

what is different?

> Talking about GCC, it does make sense to share what you mean with API.

are you saying that you didn't understand nix's response about said API? why did you even respond then? besides trolling, that is. and i did point you at said API, you can read the code or references to the code in that header.

> For most people I believe they are occupied by linking issues,

wrong, the API is not about 'linking issues'.

> which in the case of C++ refers to the ABI implemented by GCC

wrong, the gcc API that nix talked about has nothing to do with any C++ or other ABI. but then you already knew that difference, didn't you? ;)

> In the case of nix, I can of course guess that it is a reference to the newer plugin API

there's no gcc plugin API. there're a few plugin specific functions to register callbacks but other than that all public gcc symbols are available for plugin (ab)use. and this interface (functions and data structures, macros, etc) is not stable at all as you can see from my feeble attempt.

> By now I should have checked of course, but maybe you can share with me, is this the API you are struggling with?

i'm not the one struggling here with anything ;).

> I haven't worked with that API myself,

then on what grounds did you react to nix's statement?

> but I have seen GCC developers being sorry for not having it more stable.
> Whether they are just being modest, or whether they really have broken the API
> numerous times I don't know, and to be frank, I do not find you line of posting
> very helpful in conveying it either.

that's because you don't understand anything about this whole programming business yet it seemingly doesn't prevent you from posting nonsense after nonsense. you're still back at square one: figure out what API means, figure out what it is in the gcc world (never mind linux and others) and then figure out how stable they are and why. so do your homework before you spread your stupid claims about API stability.

> You see, the example from Octave using LLVM as a JIT library, is AFAIK, and intended usage of LLVM by an external project,
> and then whether the API is stable or not is a rather important issue, at least for me.

i can't imagine how anything programming related could be important for you ;). as for the API exposed by LLVM, it's the same deal as with gcc, all public symbols are there to take (over 40k of them at last count) and there're changes in there every day.

> I may of course be wrong, that Octave's usage was never intended for external usage of LLVM, so that we are more talking about an internal API, which in my mind is a different ball game.

what is LLVM's internal API? and what is 'external usage of LLVM'? and how's this 'external usage' different from LLVM's internal API?