VS 2022 is not C friendly
-
Don't know if you will find it helpful, but here's an article on configuring Visual Studio for a C++ project. It deals with the same issue you face, and might give you more insights into Visual Studio's processes - maybe. [DWinLib Build Process](https://www.codeproject.com/Articles/5292382/DWinLib-Build-Process). It can be a pain to set up, but gives a lot of power when you've figured it out.
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
The reason the VC++ static library project does not have the linkage option is that the static library does not have to link to any library, the source code file only needs to include the headers file to compile correctly. The executable project that uses your C static library must link with both static libs in the link options.
I understand. The static library I am trying to create explicitly uses calls to another static library (which I did not create). I understand that both with be involved when used by a third application. I have been using CodeBlocks as my IDE of choice. Much more straight forward and has a great editor. Uses GCC compiler.
"A little time, a little trouble, your better day" Badfinger
-
All of which may be true, but... A developer may complain that accomplishing such-n-such is difficult/tricky/whatever -- and C falls into that category. Then Microsoft comes along and says that Visual Studio will make it easy (and it definitely makes many things easy). But if VS doesn't make that one thing easy, then it SUCKS!, I mean it won't satisfy that developer's immediate need. I don't use Visual Studio much because it generally doesn't do anything I need done, not because I don't like it. What little C I still do, I don't do with Visual Studio. I really like C#, which in part may have been designed specifically for Visual Studio, so VS is very good for C# (and .net). I miss Turbo C.
-
'Xactly. Me too. Kids these days expect everything to be handed to them. I also learned on OpenVMS, which has a debugger, but it's practically unusable.
PIEBALDconsult wrote:
Kids these days expect everything to be handed to them.
He is no kid :rolleyes:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Slacker007 wrote:
A lot of members here at Code Project love to hate on Visual Studio for no intelligent reason at all.
But they express undying love for some other bit of technology? Which bit is that exactly?
-
I selected static library project, set the parameters that were given. It has everything to do with VS.
"A little time, a little trouble, your better day" Badfinger
If you selected 'static library project' it is set to CREATE a static library. It has everything to do with _understanding_ VS. If you need one static library to depend upon another then you must understand _how_ to add the dependency to VS. Setting the project type does not make it recursively able to link to other projects of that same type. I believe you would have had to add the dependency to Borland products in a similar manner. (At least I recall having to do so in the past - just the extension differed if memory serves. Or COFF vs LIB, or something.) And, logically, it is more common for an executable to link to the libraries, not one library to link to another. I've never heard of nested libraries, but I suppose it is possible.
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
If you selected 'static library project' it is set to CREATE a static library. It has everything to do with _understanding_ VS. If you need one static library to depend upon another then you must understand _how_ to add the dependency to VS. Setting the project type does not make it recursively able to link to other projects of that same type. I believe you would have had to add the dependency to Borland products in a similar manner. (At least I recall having to do so in the past - just the extension differed if memory serves. Or COFF vs LIB, or something.) And, logically, it is more common for an executable to link to the libraries, not one library to link to another. I've never heard of nested libraries, but I suppose it is possible.
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
It makes a lot sense to nest libraries. I have used that approach many times. Everyone has. My Font library uses GLFW library to handle rendering. The font library is used by a higher level application to handle I/O to screen. My biggest problem with VS is that it cannot see my includes files and libraries. Grrr. #include fails not matter how I reference that the directory it is located in. D:\code\glfw3.3.8\include NOT A TYPO ANYWHERE VS BAD
"A little time, a little trouble, your better day" Badfinger
-
It makes a lot sense to nest libraries. I have used that approach many times. Everyone has. My Font library uses GLFW library to handle rendering. The font library is used by a higher level application to handle I/O to screen. My biggest problem with VS is that it cannot see my includes files and libraries. Grrr. #include fails not matter how I reference that the directory it is located in. D:\code\glfw3.3.8\include NOT A TYPO ANYWHERE VS BAD
"A little time, a little trouble, your better day" Badfinger
jmaida wrote:
My biggest problem with VS is that it cannot see my includes files and libraries.
The steps for each step are outlined in the article I linked to. After dragging the include files into VS you must still specify the paths in the include section of the project settings, and you have to set libraries in another place in the settings as I outline there. Pretty simple once you understand it, but learning that was not as simple as it could have been - I agree with that. It would be nice if dragging a file into the explorer automatically added the appropriate path to the settings, but would require looking at relative paths as well as absolute, since both are acceptable in the project settings page.
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
It makes a lot sense to nest libraries. I have used that approach many times. Everyone has. My Font library uses GLFW library to handle rendering. The font library is used by a higher level application to handle I/O to screen. My biggest problem with VS is that it cannot see my includes files and libraries. Grrr. #include fails not matter how I reference that the directory it is located in. D:\code\glfw3.3.8\include NOT A TYPO ANYWHERE VS BAD
"A little time, a little trouble, your better day" Badfinger
PS -
#include- 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.Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
-
I TOTALLY disagree. The code I am working with is just a simple basic C libary. In VS I chose static library, etc. The problem is VS is way too complicated, trying to do to many things for too many types of language applications. I have used VS off and on for years so I know what I am talking about. I came back to it because of potential conversion of a large graphics application that will be "potentially" ported to it. I am quickly changing my mind as to whether it is worth it or not. The application is mostly window's agnostic.
"A little time, a little trouble, your better day" Badfinger
jmaida wrote:
The problem is VS is way too complicated
Well, I totally disagree with you on that. And I have been using it, or its predecessors, for almost thirty years. I have created complete applications, and static and dynamic libraries, using C, C++, C# and even VB.NET, so I also know what I am talking about.
-
It makes a lot sense to nest libraries. I have used that approach many times. Everyone has. My Font library uses GLFW library to handle rendering. The font library is used by a higher level application to handle I/O to screen. My biggest problem with VS is that it cannot see my includes files and libraries. Grrr. #include fails not matter how I reference that the directory it is located in. D:\code\glfw3.3.8\include NOT A TYPO ANYWHERE VS BAD
"A little time, a little trouble, your better day" Badfinger
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.
-
I have been trying to create a static library (in C) that uses another published static library. No where does VS do I have link options to include that library. VS SUCKS
"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... :laugh:
-
I have been trying to create a static library (in C) that uses another published static library. No where does VS do I have link options to include that library. VS SUCKS
"A little time, a little trouble, your better day" Badfinger
I never had an issue with VS, and it doesn't suck for me. For you, yeah, but I wonder why. :laugh:
-
I TOTALLY disagree. The code I am working with is just a simple basic C libary. In VS I chose static library, etc. The problem is VS is way too complicated, trying to do to many things for too many types of language applications. I have used VS off and on for years so I know what I am talking about. I came back to it because of potential conversion of a large graphics application that will be "potentially" ported to it. I am quickly changing my mind as to whether it is worth it or not. The application is mostly window's agnostic.
"A little time, a little trouble, your better day" Badfinger
Ever seen a simple IDE?
-
Ever seen a simple IDE?
-
I have been trying to create a static library (in C) that uses another published static library. No where does VS do I have link options to include that library. VS SUCKS
"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
-
It makes a lot sense to nest libraries. I have used that approach many times. Everyone has. My Font library uses GLFW library to handle rendering. The font library is used by a higher level application to handle I/O to screen. My biggest problem with VS is that it cannot see my includes files and libraries. Grrr. #include fails not matter how I reference that the directory it is located in. D:\code\glfw3.3.8\include NOT A TYPO ANYWHERE VS BAD
"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
-
If you selected 'static library project' it is set to CREATE a static library. It has everything to do with _understanding_ VS. If you need one static library to depend upon another then you must understand _how_ to add the dependency to VS. Setting the project type does not make it recursively able to link to other projects of that same type. I believe you would have had to add the dependency to Borland products in a similar manner. (At least I recall having to do so in the past - just the extension differed if memory serves. Or COFF vs LIB, or something.) And, logically, it is more common for an executable to link to the libraries, not one library to link to another. I've never heard of nested libraries, but I suppose it is possible.
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
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
-
The irony is, I love doing C in VS Code. But, it's harder to get that going property with debugging, etc. than doing C in VS.
Jeremy Falcon
-
jmaida wrote:
My biggest problem with VS is that it cannot see my includes files and libraries.
The steps for each step are outlined in the article I linked to. After dragging the include files into VS you must still specify the paths in the include section of the project settings, and you have to set libraries in another place in the settings as I outline there. Pretty simple once you understand it, but learning that was not as simple as it could have been - I agree with that. It would be nice if dragging a file into the explorer automatically added the appropriate path to the settings, but would require looking at relative paths as well as absolute, since both are acceptable in the project settings page.
Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver
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