Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Track preprocessor of Code Completion for Workspace level and Project evel #2059

Closed
mrcancer91 opened this issue Jul 14, 2018 · 1 comment
Closed
Labels

Comments

@mrcancer91
Copy link

mrcancer91 commented Jul 14, 2018

Hi,

Firstly I want to thank you for the Track preprocessor block feature of Code Completion. It really saves hours of reading the source codes.

I'm trying to distinguish the difference between preprocessor of Workspace Level and Project Level. Is there any rule for the priority of macro? I read the page Using clang code-completion with CodeLite but still confusing :(
For example, I have one Workspace with two projects (e.g P1, P2), P1 and P2 are two parts of an embedded system project) and below macros inside source codes:

SUPPORT_A=y
SUPPORT_B=y
SUPPORT_C is turned off
SUPPORT_D is turned on in P1 but turned off in P2

by using Track preprocessor block feature, I checked the option inside Settings | Code Completion | Colouring | Track preprocessor blocks.
Then I paste the macro set into Workspace Settings|Code Completion

Workspace Level: 
	SUPPORT_A=y
	SUPPORT_B=y
	
Project Level: 
	P1: 
		SUPPORT_A=y
		SUPPORT_B=y
		SUPPORT_D=y
		
	P2: 
		SUPPORT_A=y
		SUPPORT_B=y

and the result with SUPPORT_A, SUPPORT_B, SUPPORT_C works well for both P1 and P2. But SUPPORT_D now shows up at both P1,P2 if I set SUPPORT_D=y in Workspace Level.

Can current CodeLite support such feature that SUPPORT_D is disabled in P2 but active in P1?

My CodeLite is 12.0.4 - Windows 7 x64

@stale
Copy link

stale bot commented Sep 29, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Sep 29, 2019
@stale stale bot closed this as completed Oct 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant