3 ms·

Could you elaborate a bit on this statement - "SLED is poweful enough to learn how to build your project on its own". How does this work?

by dman 11y ago

slededit 11y ago
One of the problems with having a non-IDE try to parse your code is it doesn't know how its supposed to be built. I put a lot of effort to "guess" your include directories so that libclang could do a half decent job at figuring out the code. When that fails it tries to make as much sense as possible with an incomplete syntax tree - this part is still very much a work in progress.
- dman 11y ago
  I dont know if you have looked at these options - 1. Have wrapper scripts like sledgcc and sledg++ that keep track of compiler flags passed into them. This way users can just change the compiler used in their build scripts and you will be good to go. 2. http://clang.llvm.org/docs/JSONCompilationDatabase.html http://clang.llvm.org/docs/JSONCompilationDatabase.html seems to be a good option. Its reasonably easy to get your build system to emit this and a few build systems can even do this out of the box.
  - slededit 11y ago
    Another option I'm exploring is using the debug info embedded in the executable. There's lots of good info there.
- roccod 11y ago
  The problem with tools which try to understand the code themselves is that there is a mismatch between what is build by for example a Makefile and what the editor sees. We are building embedded software using a huge pile of Makefiles and using cross compilers using a lot of product dependent #defines. What is required for us is: find declaration/implementation, find usages of function, find applicable defines, have no false positives for functions which are behind compile options and are #ifdeffed out. The only IDE which works correctly is eclipse CDT. I think it works by scanning the make processes' output for defines. Are there other good tools which work ok for my scenario ?

Could you elaborate a bit on this statement - "SLED is poweful enough to learn how to build your project on its own". How does this work?

by dman 11y ago

Could you elaborate a bit on this statement - "SLED is poweful enough to learn how to build your project on its own". How does this work?

slededit 11y ago

One of the problems with having a non-IDE try to parse your code is it doesn't know how its supposed to be built. I put a lot of effort to "guess" your include directories so that libclang could do a half decent job at figuring out the code. When that fails it tries to make as much sense as possible with an incomplete syntax tree - this part is still very much a work in progress.

dman 11y ago
I dont know if you have looked at these options - 1. Have wrapper scripts like sledgcc and sledg++ that keep track of compiler flags passed into them. This way users can just change the compiler used in their build scripts and you will be good to go. 2. http://clang.llvm.org/docs/JSONCompilationDatabase.html http://clang.llvm.org/docs/JSONCompilationDatabase.html seems to be a good option. Its reasonably easy to get your build system to emit this and a few build systems can even do this out of the box.
- slededit 11y ago
  Another option I'm exploring is using the debug info embedded in the executable. There's lots of good info there.
roccod 11y ago
The problem with tools which try to understand the code themselves is that there is a mismatch between what is build by for example a Makefile and what the editor sees. We are building embedded software using a huge pile of Makefiles and using cross compilers using a lot of product dependent #defines. What is required for us is: find declaration/implementation, find usages of function, find applicable defines, have no false positives for functions which are behind compile options and are #ifdeffed out. The only IDE which works correctly is eclipse CDT. I think it works by scanning the make processes' output for defines. Are there other good tools which work ok for my scenario ?