search

LearnGraphicsProgramming / Tag2D

(todo)
MIT License
3 stars 0 forks source link

Incorrect or not defined C++ version for Common project #3

Closed lexzor closed 3 months ago

lexzor commented 3 months ago

After the last configuration commit, it seems the C++ version of Common project it's the wrong one (or it's not defined).

image

It seems the C++98/03 it's used for the project in cause.

DaaaPaul commented 3 months ago

What is that file? I could not find it

lexzor commented 3 months ago

What is that file? I could not find it

What file? The __cplusplus it's a macro which it's defined automatically by the C++ language. The 199711L represent a not configured version of C++ and the default one. (More info: https://learn.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-170)

lexzor commented 3 months ago

I'm reopening this. It seems adding cppdialect "C++20" in BuildCommon.lua override the dialect version with C++14:

image

Removing the BuildCommon.lua from premake5.lua will set the correct C++ version when using files from common project into others.

Don't get it why it's not working.

lexzor commented 3 months ago

It seems adding kind "StaticLib" to the BuildCommon.lua solve the error.

I guess we can stick with this solution and not building the common project?

DaaaPaul commented 3 months ago

Interesting, how did you come up with that solution?

Yes I believe it is actually fit for common project to be StaticLib

lexzor commented 3 months ago

I just saw the difference between the 3 projects premake configurations. I tested with it.

I feel like changing kind to StaticLib may be a temporary solution until we come with something better. It's actually not a shared library and the solution it seems superficial.. :(

CMDR-JohnAlex commented 3 months ago

Did we want to turn Common into a static library? If you're getting an error about __cplusplus when editing in the Common project, it is because the Common project is set to nothing, no language or anything. That's because those files will be included by the Server or Client so it is just the IDE saying "this isn't defined" when it will be in the Server and Client projects. Since I'm pretty sure this shouldn't be giving any actual compiler errors, there isn't a problem other than the intelisense being annoying.

We can fix it by making Common a static library and setting the C++ version to C++20 yes, or we could probably just keep the kind to None and add the premake line to use C++20? Need to test. Either solution sounds good, but if we make Common a static library, we need to change the client and server to link it.

CMDR-JohnAlex commented 3 months ago

So like we just chatted about, intellisense is being annoying and it would be worth turning Common into a static library and making sure server and client link it.

lexzor commented 3 months ago

This is the behavior i observed:

  1. If no cppdialect it's set for common project, it will assume C++98/03.
  2. If the option cppdialect "C++20" exists under common project configurations, C++14 it's assumed.
  3. Making it SharedLib will work as expected.

Also, some linking errors occurs when trying to use files under common to Client or Server project, solved here by changing their build configuration files: 82f9c43b200c0f8db1fa30533848f7f806304a16.

So like we just chatted about, intellisense is being annoying and it would be worth turning Common into a static library and making sure server and client link it.

It's not Intellisense, building fails too.