Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/msvc #8201

Merged
merged 35 commits into from
Jan 14, 2021
Merged

Feature/msvc #8201

merged 35 commits into from
Jan 14, 2021

Conversation

memsharded
Copy link
Member

@memsharded memsharded commented Dec 12, 2020

Changelog: Feature: Add new msvc compiler setting and preliminary support in conan.tools.cmake generator and toolchain.
Docs: conan-io/docs#1991

Close #3573

It is providing a compatible_packages approach to compatibility with Visual Studio compiler.

  • Support in conan.tools.microsoft following in a different PR
  • Support for intel compiler will follow in a different PR, lets first do the very basics.
  • Auto-detect for profile should probably be delayed until it is way more stable, not being tackled now.
  • Definition of the VS IDE version to use for a given compiler version (when not the default) will require improving the "configuration" of the toolchains, that will be done in other PRs, at the moment only the default compiler-version <=> VS IDE version is supported

@memsharded memsharded marked this pull request as draft December 12, 2020 22:05
@danimtb
Copy link
Member

danimtb commented Dec 14, 2020

If it is possible I would add the compatibility by default to the Visual Studio compiler if we want to encourage users to move to this msvc compiler. In ConanCenter we can generate new configurations now, but generating all visual studio packages twice will be too much IMO. Probably we will need to do the compiler switch in Conan 2.0

@SSE4
Copy link
Contributor

SSE4 commented Dec 14, 2020

is it possible to use a trick similar to Intel's base_compatible?

@danimtb
Copy link
Member

danimtb commented Dec 15, 2020

yes, something similar to that in package ID but it should be applied by default in conan 1.X IMO

@SSE4
Copy link
Contributor

SSE4 commented Dec 15, 2020

to clarify, are we proposing one-way (one-directional) compatibility layer?
e.g. the following profile:

compiler = Visual Studio
compiler.version = 15

will be able to use packages from:

compiler = msvc
compiler.version = 1928

but not vice versa

@memsharded memsharded requested review from czoido and lasote December 17, 2020 16:56
return

compatible = self.clone()
version = compatible.settings.compiler.version
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
version = compatible.settings.compiler.version
version = compatible.settings.get_safe("compiler.version")


compatible = self.clone()
version = compatible.settings.compiler.version
runtime = compatible.settings.compiler.runtime
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
runtime = compatible.settings.compiler.runtime
runtime = compatible.settings.get_safe("compiler.runtime")

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nop, at this point, using the msvc compiler, the compiler.runtime must be defined, otherwise I want it to raise, not to continue silently. Why would you want/allow this to be undefined here? It is not possible in the settings (it doesn't have a None value)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's very possible settings.yml might be modified by the user, either manually, or by running conan config install. user may add None value or remove compiler.runtime sub-setting completely. IMO code should be reliable for custom settings, as we're allowing them and promote it as a first-class feature (especially for Enterprise users).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far this would be an unsupported case, the msvc compiler always has a runtime, it is not possible to compile without it. What does a None value means? What is the use case? It is important to code new features initially more restrictive/limited scope, and learn from use cases, better than be relaxed, allow use cases that we completely ignore and that might have other implications. I strongly prefer to evolve from the basic "canonical" use case, and account for variants and special use cases later.

compatible = self.clone()
version = compatible.settings.compiler.version
runtime = compatible.settings.compiler.runtime
runtime_type = compatible.settings.compiler.runtime_type
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
runtime_type = compatible.settings.compiler.runtime_type
runtime_type = compatible.settings.get_safe("compiler.runtime_type")

_visuals = {'19.0': '14',
'19.1': '15',
'19.2': '16'}
compatible.settings.compiler.version = _visuals[version]
Copy link
Contributor

@SSE4 SSE4 Dec 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may raise, need a sanity check (maybe deserves a test)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, this is a preliminary implementation, this needs to be improved.

runtime_type = compatible.settings.compiler.runtime_type

compatible.settings.compiler = "Visual Studio"
version = str(version)[:4]
Copy link
Contributor

@SSE4 SSE4 Dec 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may raise, need a sanity check (maybe deserves a test)

@@ -48,6 +48,15 @@ def get_generator(conanfile):

compiler = conanfile.settings.get_safe("compiler")
compiler_version = conanfile.settings.get_safe("compiler.version")

if compiler == "msvc":
version = compiler_version[:4] # Remove the latest version number 19.1X if existing
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this line (and the line below) may raise, need sanity checks (and maybe tests)

@memsharded memsharded marked this pull request as ready for review January 13, 2021 19:51
conans/client/conf/__init__.py Outdated Show resolved Hide resolved
@@ -15,6 +15,14 @@ def _check_cppstd(settings):
cppstd = settings.get_safe("cppstd")
compiler_cppstd = settings.get_safe("compiler.cppstd")

if compiler == "msvc":
# This is hardcoded at the moment, because the minimum defined version is 19.0, with c++14
# TODO: When older versions of msvc are defined in settings, cppstd can be None
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# TODO: When older versions of msvc are defined in settings, cppstd can be None
# TODO: Decide if we want to force the user to provide the 'cppstd' value always

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have better removed the None value in settings leaving: cppstd: [14, 17, 20]. Not defining it will raise an error. Current design was especulative, assuming older VS versions. For the current versions cppstd: [14, 17, 20] is the correct definition, lets wait to handed this in the settings_preprocessor until we really have the problem because defining older versions.

In that case we might want to add something like cppstd: [undefined, 14, 17, 20] instead of None, in this way, it is still explicit and doesn't allow not defining it. The internal helpers like cppstd_flag should account for this, but this can wait.

@memsharded memsharded merged commit 00c7cc2 into conan-io:develop Jan 14, 2021
@memsharded memsharded deleted the feature/msvc branch January 14, 2021 16:12
liu-kan added a commit to liu-kan/gSMFRETda that referenced this pull request Nov 23, 2021
liu-kan added a commit to liu-kan/gSMFRETda that referenced this pull request Nov 23, 2021
liu-kan added a commit to liu-kan/gSMFRETda that referenced this pull request Nov 23, 2021
1929->19.29

protobuf:shared=True compiler.cppstd=14
liu-kan added a commit to liu-kan/gSMFRETda that referenced this pull request Nov 23, 2021
1929->19.29

protobuf:shared=True compiler.cppstd=14

MT
liu-kan added a commit to liu-kan/gSMFRETda that referenced this pull request Nov 23, 2021
1929->19.29

protobuf:shared=True compiler.cppstd=14

MT

14cppstd
liu-kan added a commit to liu-kan/gSMFRETda that referenced this pull request Nov 24, 2021
[no ci] conan-io/conan#8201 conan-io/conan#3311

1929->19.29

protobuf:shared=True compiler.cppstd=14

MT

14cppstd

[no ci] conan profile compiler=msvc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Incorrect handling of MSVC versions
5 participants