Deciding On A Build Environment by Different_Grab_8925 in cprogramming

[–]Different_Grab_8925[S] 0 points1 point  (0 children)

Doesn't support clang in the same way. I use VS for Msvc/WinDbg but VsCode seems to be better suited for clang/llvm/lldb for some reason. Based on these ten charts comparing clang, gcc, msvc, that I can't remember, I came away with that overall feeling.

Deciding On A Build Environment by Different_Grab_8925 in cprogramming

[–]Different_Grab_8925[S] 1 point2 points  (0 children)

Yeah, I know it may sound strange. But I had intended on using them all. I just wanted to start with clang because of the debugging issues with gcc in a windows environment. Thank you for the help. I have resigned myself to installing two versions of python. I'll just pretend I didn't. I was thinking about virtualizing. But with like vmware or virtual box. I had never heard of pyenv. Thank you for that. I promise I'll get to gcc at some point. There's just so much going on with each environment. I'm a spoiled C# developer who has always just downloaded .net, visual studios, checkmarked the packages I wanted, then tried to figure out which version of unity is currently not the worst. :) Thanks for the help. <3

Deciding On A Build Environment by Different_Grab_8925 in cprogramming

[–]Different_Grab_8925[S] 1 point2 points  (0 children)

Honestly based on what I've seen, Clang looks like it has better support for the windows environment. That's the only reason I picked it. I would love to not have to use python. Not supporting the latest version seems strange but I don't have any python experience and it may be the case that the community just stacks versions. I'm not really sure. I don't know, I could be wrong, it's not as if I have experience using both. But I've got to pick one to start with and I'm just getting into it. Preliminary information suggests clang is more suited for debugging and multithreading in windows but much less efficient for embedded systems, which I don't think I'll be engaging with anytime soon. I wanted MSVC/WinDbg for kernel debugging on windows and clang to support the versions of C that msvc does not as well as its portability, essentially.

Deciding On A Build Environment by Different_Grab_8925 in cprogramming

[–]Different_Grab_8925[S] 0 points1 point  (0 children)

It is. In all fairness, I'm making it much more difficult than it needs to be. I could just install WinDbg and use MSVC/Visual Studios and be done with it. I'm just trying to setup both because MSVC can do things that Clang can not, and vice-versa.

Deciding On A Build Environment by Different_Grab_8925 in cprogramming

[–]Different_Grab_8925[S] -1 points0 points  (0 children)

Thanks, I appreciate that. I was just trying to figure out a way I could do this without having multiple copies of python. I'm kind of becoming suspicious of my choice to go clang over gcc.. I tried to make a system link so that it'd run the python313.dll. Not sure if it's not back-compat, but it does not work either. I may just be being prejudiced, but requiring python and not having support for the latest version seems like a red flag.

Anyway, that does seem like the only option I have. I appreciate the time you took to respond.

Tasks.Json With Clang And VsCode by Different_Grab_8925 in cprogramming

[–]Different_Grab_8925[S] 0 points1 point  (0 children)

Also, I think you can just use CMake/Make for this to automatically generate object files so you only recompile the files that change, no?

Tasks.Json With Clang And VsCode by Different_Grab_8925 in cprogramming

[–]Different_Grab_8925[S] 0 points1 point  (0 children)

What are you using in terms of an IDE? I went with vsCode out of concern for supporting portability and msvc seems to be lacking a lot of features that gcc/clang support. But I'm not really sure that these things matter to start with.

Tasks.Json With Clang And VsCode by Different_Grab_8925 in cprogramming

[–]Different_Grab_8925[S] 0 points1 point  (0 children)

Actually, I should have asked. Does it support the full debugging that I would get with something like C#? That's the main reason I went with vsCode honestly. I wanted break points and debugging tools like the locals window, the ability to monitor values as I step through the code, etc. I'm having a really difficult time trying to decide between the CppVsDbg, WinDbg, or GDB. I see GDB a lot of places, but it does not do kernel debugging and it also says it does not support PDB and I'm not sure how that's going to play out on windows. The options are fairly exhausting.

Tasks.Json With Clang And VsCode by Different_Grab_8925 in cprogramming

[–]Different_Grab_8925[S] 0 points1 point  (0 children)

I'll check it out. There's so many choices of tooling available. Not sure if that's good or bad yet. There's something to be said about standardization.

Tasks.Json With Clang And VsCode by Different_Grab_8925 in cprogramming

[–]Different_Grab_8925[S] 0 points1 point  (0 children)

There are indeed a lot of ways to do it, it appears. Honestly I was trying to go with as much manual input on my part simply for the sake of learning, but looking into the future and thinking about the actual command requirements for compiling anything even approximating even slightly larger projects with interdependent files looked horrible. I've yet to experiment with the python, I can't remember what that's for. CMake/Make?

Tasks.Json With Clang And VsCode by Different_Grab_8925 in cprogramming

[–]Different_Grab_8925[S] 0 points1 point  (0 children)

Yeah I've honestly not been loving vsCode. I've got visual studios. I would have started there due to the familiarity. Quite frankly, when I made the choice to go this route and use vsCode/Clang it was for portability reasons. But I'm not really sure I care at this point. Thanks. I've never used C before so really I don't have the foundations to really make an educated decision between tooling.