|
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
modified 23-Jan-23 16:02pm.
|
|
|
|
|
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.
|
|
|
|
|
doing so as we espeak.
BTW reading your article too.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Here is a suggestion. Stop ranting about something you are having problems with. Go to https://www.codeproject.com/Questions/ask.aspx[^] and post the full details, so people can try to help you. And make sure you check what you post, so you can fix any typos, and ensure that all code snippets are surrounded by the appropriate <pre> tags so it is readable, like:
#include "somefile.h"
int main()
{
printf("Hello, World!");
return 0;
}
Tags used in the above case are:
<pre lang="C++">
and
</pre>
|
|
|
|
|
Thanks Richard,
When I can compile more specific details I will do so. I have some weird problem where VS compiles the same simple C file (single file) with two different results. It's a test file from vendor's web site that uses their libraries.
Very good suggestion. A helpful one that I should have used right off. I have even suggested in the past to others. Oh well.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
jmaida wrote: VS compiles the same simple C file
No it doesn't. You need to understand the difference between Visual Studio (an Integrated Development Environment) and the C language compiler and the object linker.
|
|
|
|
|
I know the difference, Richard.
I select the same compile option in VS IDE for each C file in VS editor.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I think I have figured it out.
Something to do with project properties and whether one has code selected or project selected. They look very similar expect one has linker options. The "additional includes" are showing blank in project properties even though I have set them in project properties when code file is selected.
Very confusing. It was the includes that giving me different results between the two C file projects.
These additional includes do not always resolve the include in code.
Plus a user error in the path, but I corrected them only have them come back later.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I favor your pain. VS does things to help that simply are never documented.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
PS - #include <someHeader.h> - the '<' and '>' included headers indicate that they are in the compiler's PATH (or something like that - files like 'stdio.h' and 'vector's (without the '.h' suffix) in .cpp). #include "someHeader.h" are for files included via the projects settings includes. I have never came across the ="" nomenclature - my first instinct is to tell you to ditch it and use the "" include method. But I'm not an expert on that - all I can say is what I've done has always worked.
|
|
|
|
|
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.
modified 23-Jan-23 5:21am.
|
|
|
|
|
#include <glfw glfw3.h="">
is what editor to lounge did. Not me
#include <glfw\glfw3.h> is what was supposed to be sent.
Something was awry.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Well you could have used the Edit button below the message to correct it.
|
|
|
|
|
I know. I just didn't see the first time.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
You can link to static lib from a static lib in VS in C. I've done it, but I'm not gonna tell you how. Why? Because of your attitude. Life's too short. Keep on Googling.
Jeremy Falcon
|
|
|
|
|
Done that, too.
This is another problem related to compilation and include files.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
David O'Neil wrote: If you selected 'static library project' it is set to CREATE a static library
Home dude isn't here to learn. He's here to rant.
Jeremy Falcon
|
|
|
|
|
BS. Not true.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
A static library cannot use another static library. What exactly do you mean? Honestly VS is perfectly fine, it's, as almost always, the users... 
|
|
|
|
|
It's another problem related to include files and VS. Not static linking with static.
Sorry premature conclusion.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Try again, you can still write a static lib in C in VS2022. You don't need to use pragmas either. While I'm not a fan of VS these days as it's too bloated, at least be fair and do the research before saying something sucks because it can't do something - when it can.
We're supposed to be mature professionals. Supposed to be...
Jeremy Falcon
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
