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

Question: how to handle projects with multiple build configurations? #112

Closed
stsquad opened this issue Nov 9, 2018 · 5 comments
Closed

Comments

@stsquad
Copy link

stsquad commented Nov 9, 2018

The project I work on the most (QEMU) has multiple build configurations. When I capture build commands with bear it happily fetches each compile command for a given file in it's various configuration. However when I turn on ccls-mode in Emacs I end up with large chunks of the code greyed out because it's using only one of the build calls to work out what is visible.

Is there anyway I can either cycle the build command used for a given file for different build configurations?

@stsquad stsquad changed the title Question: how to handle projects with multiple build configurations Question: how to handle projects with multiple build configurations? Nov 9, 2018
@MaskRay
Copy link
Owner

MaskRay commented Nov 9, 2018

Related: #96

I'm considering making ccls-*-skipped-ranges a minor mode that can be toggled. https://github.com/maskray/emacs-ccls/blob/master/ccls-semantic-highlight.el#L273

@stsquad
Copy link
Author

stsquad commented Nov 9, 2018

Out of interest how does it decide which options to use when viewing header files? We have quite a lot of #ifdef magic and header poisoning or multiple expansions in the QEMU source tree. For example our helper macros are included multiple times to generate different tables and declarations.

@MaskRay
Copy link
Owner

MaskRay commented Nov 10, 2018

You may read a bit about https://github.com/MaskRay/ccls/wiki/Initialization-options#indexmultiversion-index-a-file-in-each-translation-unit-that-includes-it

This is a very difficult problem. A header can be compiled differently and it is difficult to decide what actions should be taken when you edit the header file. If you edit every source file that includes the header, the performance suffers a lot and it is also difficult to implement.

I'm inclined to close this issue as this is a known problem of almost every tool. I've put some thoughts on the wiki and I'd like to help with the situation, but there does not need to be an open issue to track that. If you have any thoughts, welcome to chat, either here or the gitter channel.

@MaskRay MaskRay closed this as completed Nov 10, 2018
@MaskRay
Copy link
Owner

MaskRay commented Nov 11, 2018

Added a section https://github.com/MaskRay/ccls/wiki/FAQ#multi-version-headers

A header can be included in different translation units with different compiler flags. It may behave differently via #ifdef. Ideally there should be some mechanism to switch among different views (compiler flags) when you are editing the file.

For efficiency, a header is only indexed with one set of compiler flags, so either the #if block or #else is indexed, the other is left blank.

For macros, there is code to track different usage, thus you may find them able to jump to multiple targets. index.multiVersion is an experimental option to index every version to certify that the author is aware of this issue :) It may not be very useful though. It is of type number but not boolean as the author is also aware of other dimensions of the multi-version problem.

@joshuisken
Copy link

To cope with multiple build configurations: would it be possible to run multiple ccls processes and switch on the fly while editing a single file, from one language server to another?
I'm using platformio, having two build targets (for instance compilation for esp32 and atmel), with different build settings. Platformio uses '-e env' to build binaries for different targets.
Having two servers allows switching build context while viewing/editing the source, think that would be nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants