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

Add headers to CMakeLists.txt and add .h extension #246

Open
davidhunter22 opened this issue May 5, 2022 · 8 comments
Open

Add headers to CMakeLists.txt and add .h extension #246

davidhunter22 opened this issue May 5, 2022 · 8 comments

Comments

@davidhunter22
Copy link
Contributor

Currently the header files in include/ipr, for example include/ipr/lexer are not in the CMakeLists.txt file.
This means they do not appear in a generated Visual Studio project.
If you do add them, to the add_library CMake command, they will appear but because they have no extension they do not get any syntax highlighting.
I would suggest

  1. Add the headers to the CMakeLists.txt
  2. Add .h extensions to the files ( and fis up the relevant #include statements )
    Step 1 could be done without doing step 2.
    If you are OK with this I will submit a PR.
@GabrielDosReis
Copy link
Owner

In the toplevel CMakeLists.txt, the command target_include_directories() adds the include directory as public, with the intent that everything under that directory is intended to be part of the project. Is that not sufficient? If not, then we can do (1) without (2).

@davidhunter22
Copy link
Contributor Author

davidhunter22 commented May 6, 2022

Just to clarify. I am using the cmake by running it on the command line to generate the VS solution file and projects. In this case the header file do not show up.
If I open the souce code using the "Open Folder" in built CMake support in VS I see all the files in "Folder View" but don't see the headers in "CMake Targets View" which is sort of what I would expect. Note the header files like "lexer" still get no intellisense, syntax highlighting, or other VS goodies which isn't great.
I will investigate why the target_include_directories does not seem to work.

Are you are using VS Code rather than VS?

BTW I am using CMake 3.23 targeting the "Visual Studio 17 2022" generator

@davidhunter22
Copy link
Contributor Author

My understanding is that target_include_directories only adds the directory to the command line, normally using a -I flag. I don't think it has any effect on the visibility of those files in a generated VS project. I think to do that you have to add the files to the add_library or equivalent command. Or you can you the target_sources command after add_library.
It would probably be possible to use globbing rather than list the files out but I seem to recall that is a bit frowned on by the CMake mavens.

The target_sources way would require adding

target_sources(ipr PRIVATE
    ${PROJECT_SOURCE_DIR}/include/ipr/attribute
   ...
    ${PROJECT_SOURCE_DIR}/include/ipr/lexer)

Note this still does not add intellisense etc... I will see if this is possible without adding an extension

@GabrielDosReis
Copy link
Owner

Note the header files like "lexer" still get no intellisense, syntax highlighting, or other VS goodies which isn't great.

Now, I am confused as to what the real issue is :-)
Is it that you're not getting IntelliSense in VS? I think that is a VS bug/defect/limitation. When I open the files in VS Code, I get syntax highlighting and everything (except VS IntelliSense, of course). VS Code recognizes decades-old practices in the OSS community of using in-source language marker, e.g. -*- C++ -*-, which appears in all source files. I wouldn't want to rename the source files just to work around a VS defect. Maybe report it to VS DevCom portal and point out the VS Code support? Also, this style of header file name and issue should be present with things like <vector>

@davidhunter22
Copy link
Contributor Author

There are really two issues.

  1. The header files don't appear in Visal Studio at all when you generate the solution/project files
  2. Even if you add them, via CMake or directly in Visual Studio there is no intellisense, syntax highlighting etc..
    I thin VS Code works differently to VS in this respect.
    Visual Studio does not support -- C++ --, I think those are called modelines. It mostly recognizes the lanagage using the file extension.
    In the case of standard library header like I think magic occurs. I noticed htis because the file called "utility" in the IPR project did get intellisense etc.. It's the only one who name happens to mach a standard library header. I asked a question https://developercommunity.visualstudio.com/t/How-does-Visual-Studio-recognize-c-sta/10032547?from=email&viewtype=all&space=62&scope=follow&q=intellisense+for+extnsionless+headers on how this magic works as I may be able to use it.
    In the short tem can I add the
target_sources(ipr PRIVATE
    ${PROJECT_SOURCE_DIR}/include/ipr/attribute
   ...
    ${PROJECT_SOURCE_DIR}/include/ipr/lexer)

This should have no downside for Visual Studio Code ot people using ninja etc... and will at least make the file appear in Visual Studio.

@GabrielDosReis
Copy link
Owner

In the short tem can I add the

Do you get IntelliSense with that change?

I think those are called modelines

Yes.
You can also upvote the request for VS to support modelines

@davidhunter22
Copy link
Contributor Author

The change does not mean you get itellisense but at least you can see the files.
You can switch the "Map extensionless files" to be C++ but that has a few issues. See https://developercommunity.visualstudio.com/t/How-does-Visual-Studio-recognize-c-sta/10032547?from=email&viewtype=all&space=62&scope=follow

@GabrielDosReis
Copy link
Owner

You can switch the "Map extensionless files" to be C++ but that has a few issues.

Requesting VS to support modelines - just like VS Code and other popular editors do - is the righteous move, instead of working around and programming to VS. Let's continue to push on that.

There is one review comment left unaddressed on your PR before commit. Thanks!

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

2 participants