Unable to compile ClangCompletion cbplugin

[stahta01]

@yvesdm3000: I think I am ready to start editing the clanglib-unix.cbp file and testing, then maybe it will be ready for git pull request.
But, I have some questions.

Is this project supposed to be for a Code::Blocks installed configuration or for a Self-Built Code::Blocks that is NOT installed?
In other words, do these commands work "pkg-config --libs codeblocks" and "pkg-config --cflags codeblocks".
If they work, then Code::Blocks is likely installed.
If they do NOT work then likely Self-Built Code::Blocks that is NOT installed.

Tim S.

[yvesdm3000]

Is this project supposed to be for a Code::Blocks installed configuration or for a Self-Built Code::Blocks that is NOT installed?
In other words, do these commands work "pkg-config --libs codeblocks" and "pkg-config --cflags codeblocks".
If they work, then Code::Blocks is likely installed.
If they do NOT work then likely Self-Built Code::Blocks that is NOT installed.

Tim S.

If Code::Blocks is installed, the pkg-config should work. I however would assume that if Code::Blocks is installed in an alternative location (like in all of my cases, I need to work in environments where I don't have root access nor codeblocks preinstalled), one should really use PKG_CONFIG_PATH to point to a location where the codeblocks.pkg file is found. Using an uninstalled Code::Blocks would cause many problems imho.

Yves

[stahta01]

I created the pull request.

Try the project and verify it works for you.
The target no_pch does NOT work because the code has PCH related issues.
I will verify my patch to fix that is correct in the next few days.

PCH stands for Precompiled Header for Code::Blocks that normally means "sdk.h".

I added some before build steps to display the output of the commands "pkg-config --libs codeblocks" and "pkg-config --cflags codeblocks".
FYI: If you use the EnvVars plugin to set PKG_CONFIG_PATH you will likely have to exist out of Code::Blocks to see the setting take effect.

Tim S.

[yvesdm3000]

I accepted the pull request. Thanks !
It builds for me on Centos7 x64 and my own compiled wx 2.8.

Any reason why you've replaced the release and debug build with PCH and NO_PCH? I intended to use the 'Release' one with optimizations enabled and the 'Debug' one without optimizations but with debugging symbols (and assertions at a later stage). I could imagine to use pch for release and no_pch for the debug build, but the naming would then indicate a detail instead of the intention...

I'm OK with removing the 'lib' in front since it's not needed. Initially I had problems where C::B did'nt want to accept the plugin so one starts doing every detail exactly the same as an example plugin until you find what's wrong. I don't actually know why all other plugins have 'lib' in front of them on Linux ?

Yves

[astrapi]

I created the pull request.

Try the project and verify it works for you. For Yves I suppose
The target no_pch does NOT work because the code has PCH related issues.
I will verify my patch to fix that is correct in the next few days.

PCH stands for Precompiled Header for Code::Blocks that normally means "sdk.h". Thanks !

I added some before build steps to display the output of the commands "pkg-config --libs codeblocks" and "pkg-config --cflags codeblocks".
FYI: If you use the EnvVars plugin to set PKG_CONFIG_PATH you will likely have to exist out of Code::Blocks to see the setting take effect.

Tim S.

I've successfully built it (Youhouu !!) I juste have to make some changes :
translationunit.h:54         assert( first.m_id == second.m_Id );  //I change the m_id in m_Id
I change in linker settings wx-config --libs in wx-config --version=2.8 --libs
And (like you said), compiling with g++-5 and -std=c++14 didn't work so I take it off too.
And it compile I had my .zip .so and .cbplugin, if I installed it from cbplugin or install it manually, it get me the same as before, impossible to remember what I tick (like parse documentation) (maybe it's because it's in a folder where it must be root ? but the other plugin has the same .zip ant it works so...), and if I disable the code completion plugin, I didn't see anymore the reparse project option.
If I open a other project, the completion will not work on it (sometimes...), but if I open it alone, it will... (the clang lib tool bar is grey)
It doesn't complete function argument... Rhalala ! (it seems to be a complicated stuff this things...)


But it works for completion, it complete auto and shared_ptr , and there is no bug with chowing sometimes the pop
up documentation and sometime not. I don't see the documentation of lib that I use (SFGUI or SFML) but I see the documentation that I made.

I've compile but not install codeblocks releaser 16.01 with wx2.8, I juste have this error link with the global variable cb_release_type (I've not understand this thing)
||warning: /home/astrapi/.lib/codeBlocks/codeblocks-16.01.release/src/base: linker input file unused because linking not done|, but It's built if it can be use for something...

[yvesdm3000]

I've successfully built it (Youhouu !!) I juste have to make some changes :
translationunit.h:54         assert( first.m_id == second.m_Id );  //I change the m_id in m_Id

That's fixed in a later commit.

impossible to remember what I tick (like parse documentation)

I think the 'parse documentation' tab is not implemented yet. I copied some dialog items from the regular code-completion plugin that I think we'll also need in the end.

Documentation is currently always parsed. When you don't get documentation during code-completion, then this is because there is a timing issue that I'm aware of.
Don't expect the documentation to be feature-complete, it is not.

Regarding documentation, in the 'advanced'-tab there is now the option to use all comments as documentation and not only DoxyGen-type. That option should really be moved to the 'documentation' tag, but it's allready there ready for use.

The diagnostics-tab should all be implemented, and some '-W' options in the latest should also work, as is the 'advanced' tab.

Yves

[stahta01]

Oops, I forgot to make an CB project change that is needed.

I change in linker settings wx-config --libs in wx-config --version=2.8 --libs

Tim S.

[astrapi]

Cool cool cool !
I watch yours gits, and I'm ready to program !

[stahta01]

I missed this post by you; I am going to answer it inline.

I accepted the pull request. Thanks !
It builds for me on Centos7 x64 and my own compiled wx 2.8.

Any reason why you've replaced the release and debug build with PCH and NO_PCH? I intended to use the 'Release' one with optimizations enabled and the 'Debug' one without optimizations but with debugging symbols (and assertions at a later stage). I could imagine to use pch for release and no_pch for the debug build, but the naming would then indicate a detail instead of the intention...

I did NOT realize you plan to use the 'Debug' and 'Release' targets; I can change them back if you want. I would prefer to use lower case target names when doing that.
I will work on that before doing my next pull request.
Edited named the targets 'debug' and 'release'. in the pull request I just did.
Did I do the pull request correctly?

I'm OK with removing the 'lib' in front since it's not needed. Initially I had problems where C::B did'nt want to accept the plugin so one starts doing every detail exactly the same as an example plugin until you find what's wrong. I don't actually know why all other plugins have 'lib' in front of them on Linux ?

Yves

I removed the lib because the zipped cbplugin file does NOT like the lib prefix; this is a bug in the CB Wizard that I might try to fix in the future.

Tim S.

[yvesdm3000]

I did NOT realize you plan to use the 'Debug' and 'Release' targets; I can change them back if you want. I would prefer to use lower case target names when doing that.
I will work on that before doing my next pull request.
Edited named the targets 'debug' and 'release'. in the pull request I just did.
Did I do the pull request correctly?

Yes no problem for me

Yves