Godot: Header only classes not included in Visual Studio Project Generation.

[marstaik]

The Scons build targets specifically only look for .cpp files. Because of this, header-only classes, such as Map, CowData, and etc do not appear in the generated visual studio project files.

This means that we cannot find/search for them, unless we follow a reference to them. They do not appear in the solution explorer either for opening them manually, even if we know they are there.

I think the easiest solution here would be to just create empty cpp's for header only classes.

Alternatively, we could add .hpp for header only classes and add the scons projects to also search for .hpp in addition to .cpp

Ignoring header files in general is a bad idea IMO.

[aaronfranke]

Is there a way we can add the headers to scons without doing this? Perhaps manually listing them, or doing it for all *.h files (would this cause other issues?), or inferring based on if there's an accompanying *.cpp file next to it?

Is there a way to add references in scons without having scons actually build those files? Regardless of whether it's adding empty files or not, it would be weird to build a header for no reason.

[marstaik]

Why is that weird? You can build it individually for c++ syntax checking. Without an empty cpp, you cant check your header file without including it in some other compilation unit.

Benefits:

• It doesn't increase compile times
• It allows the linker to validate the header standalone - it solves errors with missing includes that happen to work because of the current translation unit.
• When someone does need to add things to the cpp file, it doesn't require the contributor to make the .cpp if it doesn't exist
• It catches miscellaneous errors (it already caught an unused .h from 2017)

Downsides:

• You need to make a .cpp file

[seebs]

Without an empty cpp, you cant check your header file without including it in some other compilation unit.

This is nonsensical, and I think implies that you do not understand how headers are supposed to work. You are proposing including the header in a compilation unit in order to check it without including it in some other compilation unit. But... why? This is not how C++ (or C) is supposed to work.

scons and visual studio have both been used in the past with projects that did not create dummy .cpp files to go along with headers that had no need for such files.

[marstaik]

This is nonsensical, and I think implies that you do not understand how headers are supposed to work. You are proposing including the header in a compilation unit in order to check it without including it in some other compilation unit. But... why? This is not how C++ (or C) is supposed to work.

Because it is extremely easy to make header files that only work in a single context? It seems your reply makes you sound like a complete imbecile when it comes to C++. I recommend you stop shaming people when you don't understand the benefit of verifying the self-containment of header files. It saves people issues down the line, especially for large projects.

Header files A.h can have a static function that returns class Foo without ever defining it, and it exists fine as a regular text file. Tell gcc/g++ to compile it (in order to make a .h.gch file), and it will bitch at you that Foo has no definition.

But Let B.h include some C.h (which defines Foo) before including A.h
Guess what, that file will compile fine, since the translation unit now has a definition for Foo.

However then another user comes along making D.h that includes A.h expecting it to work, and all of a sudden you lack a declaration or definition of Foo. Imagine if A.h was a complicated multi-templated class, that's just painful for the other user to have to figure out and waste their time.

Its a choice to not have cpp files, that much is true. But specifying its simply now how "C++ is supposed to work" is a dumb statement.

[seebs]

You have not told me about anything I wasn't aware of twenty years ago. Your proposed "solution" does not match the design intent of the "header file" construct, and the large variety of existing large projects in which not every header has a corresponding .c or .cpp file might reasonably be taken as evidence that many experienced programmers, who are familiar with the "problem" you describe, do not find your solution appealing or necessary.

I would suggest that you slow down a bit and allow for the remote possibility that people who have decades of experience with something are not, in fact, stupid. Sometimes, when someone sounds like "a complete imbecile" to you, it's not because you know something they don't; it's because they know something you don't. Keeping that possibility in mind will likely save you a lot of trouble down the line.

(One of the things you apparently didn't know is that I was on one of the language standard committees for a decade or so. I might have some inkling of expected use cases, best practices, and design intent.)

[marstaik]

You have not told me about anything I wasn't aware of twenty years ago. Your proposed "solution" does not match the design intent of the "header file" construct

What?
GNU C Says:

Header Files

The C++ standard specifies the entire set of header files that must be available to all hosted implementations. Actually, the word "files" is a misnomer, since the contents of the headers don't necessarily have to be in any kind of external file. The only rule is that when one #includes a header, the contents of that header become available, no matter how.

Microsoft Says:

To minimize the potential for errors, C++ has adopted the convention of using header files to contain declarations. You make the declarations in a header file, then use the #include directive in every .cpp file or other header file that requires that declaration. The #include directive inserts a copy of the header file directly into the .cpp file prior to compilation.

I don't understand how I am misusing the header file construct by adding cpp files that include said headers?

Sometimes, when someone sounds like "a complete imbecile" to you

You insulted my lack of knowledge on C++ headers which has nothing to do with the issue this thread is trying to solve trying to solve? We are just trying to get C++ headers to show up in the project outputs here.

My initial proposed solution was to generate cpp files since it has the added benefit of testing self-containment, as well as not increasing Scons parsing time or compile times.

People in the PR didn't seem to like it, and that's fine, Ill try a new approach.

scons and visual studio have both been used in the past with projects that did not create dummy .cpp files to go along with headers that had no need for such files.

I am sure they have. The current build system does not. Would you like to propose a solution instead of flaunting your knowledge? Please take your ego and go somewhere else with it, I (and many others) just want to be able to pull the repo and work on Windows with VisualStudio, or with a compilation_db.json in some other IDE without having to guess whether or not header-only files are/exist.

I have already given up on the cpp approach, people don't like the extra bloat.

I am now trying to modify Scons in a way that is supportive of headers and is as modular as our current system.

[seebs]

If you want things to show up in the "project outputs", put them there! You control the "project outputs" in question. Visual Studio works fine with any of the thousands of projects out there which use headers in the conventional way, do not try to make special dummy .cpp files corresponding to each header, and work fine out of the box.

Your misunderstanding is right around the phrase "header-only". That implies that you think that the "natural" state is to have a corresponding .cpp file for each header, and that "header-only" headers are somehow unusual or not the natural state of headers. It's more the other way around; headers are logically fully independent of .cpp or .c files, and do not need a corresponding file to exist, and never have.

Visual Studio does not require this. Neither does SCons. If something you are doing is making it seem like they expect this, that's on you.