| FAQ - Why sparse? |
| |
| Q. Why not just use gcc? |
| |
| A. Gcc is big, complex, and the gcc maintainers are not interested in |
| other uses of the gcc front-end. In fact, gcc has explicitly |
| resisted splitting up the front and back ends and having some common |
| intermediate language because of religious license issues - you can |
| have multiple front ends and back ends, but they all have to be part |
| of gcc and licensed under the GPL. |
| |
| This all (in my opinion) makes gcc development harder than it should |
| be, and makes the end result very ungainly. With "sparse", the |
| front-end is very explicitly separated into its own independent |
| project, and is totally independent from the users. I don't want to |
| know what you do in the back-end, because I don't think I _should_ |
| know or care. |
| |
| |
| Q. Why not GPL? |
| |
| A. See the previous question: I personally think that the front end |
| must be a totally separate project from the back end: any other |
| approach just leads to insanity. However, at the same time clearly |
| we cannot write intermediate files etc crud (since then the back end |
| would have to re-parse the whole thing and would have to have its |
| own front end and just do a lot of things that do not make any sense |
| from a technical standpoint). |
| |
| I like the GPL, but as rms says, "Linus is just an engineer". I |
| refuse to use a license if that license causes bad engineering |
| decisions. I want the front-end to be considered a separate |
| project, yet the GPL considers the required linking to make the |
| combined thing a derived work. Which is against the whole point |
| of 'sparse'. |
| |
| I'm not interested in code generation. I'm not interested in what |
| other people do with their back-ends. I _am_ interested in making a |
| good front-end, and "good" means that people find it usable. And |
| they shouldn't be scared away by politics or licenses. If they want |
| to make their back-end be BSD/MIT licensed, that's great. And if |
| they want to have a proprietary back-end, that's ok by me too. It's |
| their loss, not mine. |
| |
| At the same time, I'm a big believer in "quid pro quo". I wrote the |
| front-end, and if you make improvements to the semantic parsing part |
| (as opposed to just using the resulting parse tree), you'd better |
| cough up. The front-end is intended to be an open-source project in |
| its own right, and if you improve the front end, you must give those |
| improvements back. That's your "quid" to my "quo". |
| |
| |
| Q. So what _is_ the license? |
| |
| A. I don't know yet. I originally thought it would be LGPL, but I'm |
| possibly going for a license that is _not_ subsumable by the GPL. |
| In other words, I don't want to see a GPL'd project suck in the |
| LGPL'd front-end, and then make changes to the front end under the |
| GPL (this is something that the LGPL expressly allows, and see the |
| previous question for why I think it's the _only_ thing that I will |
| not allow). |
| |
| The current front-runner is the OSL ("Open Software License", see |
| http://www.opensource.org/licenses/osl.php), together with a note on |
| what makes source derivative and what does not to make it clear that |
| people can write back-ends for it without having to make those |
| back-ends available under the OSL. |
| |
| |
| Q. Does it really parse C? |
| |
| A. Yeah, well... It parses a fairly complete subset of "extended C" as |
| defined by gcc. HOWEVER, since I don't believe in K&R syntax for |
| function declarations or in giving automatic integer types, it |
| doesn't do that. If you don't give types to your variables, they |
| won't have any types, and you can't use them. |
| |
| Similarly, it will be very unhappy about undeclared functions, |
| rather than just assuming they have type "int". |
| |
| Note that a large rationale for me doing this project is for type |
| following, which to some degree explains why the thing is type-anal |
| and refuses to touch the old-style pre-ANSI non-typed (or weakly |
| typed) constructs. Maybe somebody else who is working on projects |
| where pre-ANSI C makes sense might be more inclined to care about |
| ancient C. It's open source, after all. Go wild. |
| |
| |
| Q. What other sparse resources are available? |
| |
| A. Website: http://www.kernel.org/pub/software/devel/sparse/ |
| |
| Mailing list: linux-sparse@vger.kernel.org |
| See http://vger.kernel.org/vger-lists.html#linux-sparse for subscription |
| instructions and links to archives |
| |
| Git repo: git://git.kernel.org/pub/scm/devel/sparse/sparse.git |
| gitweb: http://git.kernel.org/?p=devel/sparse/sparse.git |