On Fri, Sep 3, 2010 at 4:22 PM, Florian Goujeon <florian.goujeon@42ndart.org> wrote:
[1] Scalpel appears to be under an LGPL license, which is not Boost-compatible.
In the beginning, Scalpel was under GPL. Hartmut Kaiser, Joel de Guzman and some fellows of mine convinced me to switch under a more liberal software license. Then, I've switched to LGPL. If one day Scalpel is accepted into Boost, I'll release it under the BSL without any hesitation.
LGPL is still too restrictive for single binary distributions, Clang is under an MIT style license. On Fri, Sep 3, 2010 at 4:57 PM, Dave Abrahams <dave@boostpro.com> wrote:
On Fri, Sep 3, 2010 at 6:22 PM, Florian Goujeon <florian.goujeon@42ndart.org> wrote:
All competition is stimulating. It's beneficial for everyone. All competitors are different from each other and aim to bring a surplus value. As I said, Scalpel brings high homogeneity with Boost. It has its own unique design and I also plan to endow it with round-trip engineering capabilities.
One area that scalpel could conceivably find a niche, depending on how you do it, would be in analyzing source code without seeing the full translation unit (as you might for syntax-coloring purposes). Since CLANG is really built to be a compiler, I don't think it can do that.
Of course I realize you can't always get a correct analysis if you don't see the whole TU, but especially if you're willing to do nondeterministic parsing/backtracking, you could very easily do a really good job.
I do not think it can do that either, without seeing the whole translation unit then you are going to see a *LOT* of undefined symbols, no clue if they are a type, function, etc... etc.... It is impossible to have any kind of decent syntax-coloring without that (see the difference between the fully parsed and complete Visual Assist VS add-in compared to emacs/vi/VS/etc...), and refactoring becomes all but impossible.