VS 2022 is not C friendly
-
Typo in the post it's #include GLFW/glfw3.h (with <> brackets. If I explicit put them this post incorrect displays them) which VS flags with red underline of #include which is the signal it cannot find the file even though I have the complete path d:\code\glfw3.3.8\include in the additional includes field of the applications properties and it is a valid path to the required file VS says it cannot find the file and recommends I use some strange application called vcpkg to install it Like I say VS ______s
"A little time, a little trouble, your better day" Badfinger
If you read my post, I said to use quotation marks around the include, not '<' and '>', so
#include "somefile.h". There is a big difference. And don't put an '=' or a ' ' inside the include file (so not#include "somefile somefile.h="""- just#include "somefile.h". It isn't VS - it is GIGO.Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
guys. I am not ranting. I have done all the suggestions, checked all the boxes, VS will not recognize the include statement it's frustration. It's not the static library issue anymore. I used the GLFW test program example from their website. Simple C program. VS will flag their include as not found even when the path is fulled included as additional include GLFW folks are also working it.
"A little time, a little trouble, your better day" Badfinger
So you're the type that argues all day long - got it. You may wish to read your original post again. Clearly, you think that's not ranting. It is... but whatever.
Jeremy Falcon
-
If you read my post, I said to use quotation marks around the include, not '<' and '>', so
#include "somefile.h". There is a big difference. And don't put an '=' or a ' ' inside the include file (so not#include "somefile somefile.h="""- just#include "somefile.h". It isn't VS - it is GIGO.Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
Nah, it is not simple once you try to go outside defaults.
-
Like Jeremy, I can guarantee it isn't something on VS's end. It is responsible for more pieces of software than you or I can count to in a day. It must be something on GLFW's end with malformed headers. Does the header immediately include another header that is at another location? Is that malformed? Go that direction or another with GLFW taking responsibility, quit blaming VS. Build the code in my article on your end and go through all the instructions. Then create a GLFW project starting one file at a time without using any CMAKE or any other shortcuts. You will figure it out that way. You will never figure it out just by blaming VS.
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
Like Jeremy, I can guarantee it isn't something on VS's end. It is responsible for more pieces of software than you or I can count to in a day. It must be something on GLFW's end with malformed headers. Does the header immediately include another header that is at another location? Is that malformed? Go that direction or another with GLFW taking responsibility, quit blaming VS. Build the code in my article on your end and go through all the instructions. Then create a GLFW project starting one file at a time without using any CMAKE or any other shortcuts. You will figure it out that way. You will never figure it out just by blaming VS.
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
I will. Thank you. I blame VS because 1. Have 2 copies of exactly the same C file. 2. Put them into VS "exactly" the same way (here is where the rub is, because VS makes that more complicated than it should be as "exactly" is not what has happened) 3. one works fine, the other does not. 4. Did a difference on .project files. Not "exactly" the same. That is what I am trying to resolve. If it is user error then shame on VS for making it easy to do.
"A little time, a little trouble, your better day" Badfinger
-
So you're the type that argues all day long - got it. You may wish to read your original post again. Clearly, you think that's not ranting. It is... but whatever.
Jeremy Falcon
I do not like to argue all day long. I am looking for helpful input. I have received it and I have taking everyone's advice, but I still cannot get VS to behave. Frustrating. OK. You can call it ranting. So what. I am an extremely experienced C programmer (I have also written code in C, Fortran, Cobol, Algol, PL/I ...) as well. Writing C code since K&R first publication, so feel qualified to complain. I am retired now and doing some experimenting using GLFW's VS libraries to facilitate porting a large body of work to VS for programmers at a former employer. I will calmly say VS is not a user/programmer friendly application. I have used it on and off since it first came out and it keeps getting worse. But I will solve this problem.
"A little time, a little trouble, your better day" Badfinger
-
I will. Thank you. I blame VS because 1. Have 2 copies of exactly the same C file. 2. Put them into VS "exactly" the same way (here is where the rub is, because VS makes that more complicated than it should be as "exactly" is not what has happened) 3. one works fine, the other does not. 4. Did a difference on .project files. Not "exactly" the same. That is what I am trying to resolve. If it is user error then shame on VS for making it easy to do.
"A little time, a little trouble, your better day" Badfinger
Find the main header that controls everything. Make a single VS project with just that. Comment out all of the included headers. Even comment out the code. Get that to compile. Then uncomment one header and get that to compile. Etc. etc. If it is a big project it will take quite a while. I have gone through a process like that before. It wasn't fun, but I found the stupid effing mistake. It was my own mistake.
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
Ever seen a simple IDE?
-
Find the main header that controls everything. Make a single VS project with just that. Comment out all of the included headers. Even comment out the code. Get that to compile. Then uncomment one header and get that to compile. Etc. etc. If it is a big project it will take quite a while. I have gone through a process like that before. It wasn't fun, but I found the stupid effing mistake. It was my own mistake.
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
Code Blocks is more straight forward
"A little time, a little trouble, your better day" Badfinger
CB is specialized for C/C++ and Fortran, so it will be far simpler than VS, but again, it is not simple. BTW it was my first IDE, so I have some newbie dev experience with it, it was not hell, but it still required serious effort to configure.
-
I do not like to argue all day long. I am looking for helpful input. I have received it and I have taking everyone's advice, but I still cannot get VS to behave. Frustrating. OK. You can call it ranting. So what. I am an extremely experienced C programmer (I have also written code in C, Fortran, Cobol, Algol, PL/I ...) as well. Writing C code since K&R first publication, so feel qualified to complain. I am retired now and doing some experimenting using GLFW's VS libraries to facilitate porting a large body of work to VS for programmers at a former employer. I will calmly say VS is not a user/programmer friendly application. I have used it on and off since it first came out and it keeps getting worse. But I will solve this problem.
"A little time, a little trouble, your better day" Badfinger
Ok... whatever.
Jeremy Falcon
-
Ok... whatever.
Jeremy Falcon
-
I guess you are the whatever type. :)
"A little time, a little trouble, your better day" Badfinger
I guess you lack the self-awareness to see you proved my point about you looking to rant and argue. Since I know you're going to reply and continue this charade, you can have the last post. Still won't have the solution though.
Jeremy Falcon
-
I guess you lack the self-awareness to see you proved my point about you looking to rant and argue. Since I know you're going to reply and continue this charade, you can have the last post. Still won't have the solution though.
Jeremy Falcon
-
I guess you lack the self-awareness to see you proved my point about you looking to rant and argue. Since I know you're going to reply and continue this charade, you can have the last post. Still won't have the solution though.
Jeremy Falcon
-
I guess you lack the self-awareness to see you proved my point about you looking to rant and argue. Since I know you're going to reply and continue this charade, you can have the last post. Still won't have the solution though.
Jeremy Falcon
-
I guess you lack the self-awareness to see you proved my point about you looking to rant and argue. Since I know you're going to reply and continue this charade, you can have the last post. Still won't have the solution though.
Jeremy Falcon
-
I guess you lack the self-awareness to see you proved my point about you looking to rant and argue. Since I know you're going to reply and continue this charade, you can have the last post. Still won't have the solution though.
Jeremy Falcon
-
jmaida wrote:
#include <glfw glfw3.h=""> fails not matter how I reference that the directory it is located in. D:\code\glfw3.3.8\include NOT A TYPO ANYWHERE
Apart from the fact that the include statement is totally incorrect. And again, that is nothing to do with Visual Studio, but one for the compiler. Well, strictly speaking, it's the preprocessor, but we'll let that pass.