Skip to content

projects: drop MSVC project files for recent versions - #13311

Closed
bagder wants to merge 5 commits into
masterfrom
bagder/drop-new-msvc-proj
Closed

projects: drop MSVC project files for recent versions#13311
bagder wants to merge 5 commits into
masterfrom
bagder/drop-new-msvc-proj

Conversation

@bagder

@bagder bagder commented Apr 8, 2024

Copy link
Copy Markdown
Member

We encourage users to generate visual studio project files using CMake.

We keep project files in git for ancient visual studio versions that cmake cannot generate files for, but we no longer ship the project files in the tarballs.

(alternative take to #13296)

We encourage users to generate visual studio project files using CMake.

We keep project files in git for ancient visual studio versions that
cmake cannot generate files for, but we no longer ship the project files
in the tarballs.
@bagder bagder added build Windows Windows-specific dist labels Apr 8, 2024
@bagder

bagder commented Apr 8, 2024

Copy link
Copy Markdown
Member Author

@MarcelRaad and @jay thoughts?

@bagder

bagder commented Apr 8, 2024

Copy link
Copy Markdown
Member Author

Everything curl is now correspondingly mentioning the "generate with cmake" way: https://everything.curl.dev/build/windows.html

@jay

jay commented Apr 9, 2024

Copy link
Copy Markdown
Member

The documentation needs to be updated. Also I would include the generated VC10-12 with the tarball if the tarball can still be reproducible. I forgot we stopped doing that.

jay added 2 commits April 9, 2024 12:19
.. also add --help and /? as aliases for -help and /? options
- explain user must run generate.bat to generate legacy versions

- explain user must use cmake to generate later versions
@jay

jay commented Apr 9, 2024

Copy link
Copy Markdown
Member

I would include the generated VC10-12 with the tarball

nm. I removed the dead code for VC14 and changed the README to explain that generate.bat must be run to generate the legacy versions of Visual Studio project files and cmake must be run to generate later versions of Visual Studio project files.

vszakats
vszakats previously approved these changes Apr 9, 2024
@vszakats
vszakats dismissed their stale review April 9, 2024 18:18

'VisualStudioSolution, VS2017, Debug, x86, Schannel, Build-only' AppVeyor job needs update

@bagder

bagder commented Apr 9, 2024

Copy link
Copy Markdown
Member Author

Ah yes, appveyor uses generate.bat for the VS2017 build so we either need to keep support for that, or switch to generating the project files with cmake there...

@vszakats

vszakats commented Apr 9, 2024

Copy link
Copy Markdown
Member

Ah yes, appveyor uses generate.bat for the VS2017 build so we either need to keep support for that, or switch to generating the project files with cmake there...

Strong vote for the latter. It would also serve as an example for how to do that.

@MarcelRaad

MarcelRaad commented Apr 9, 2024

Copy link
Copy Markdown
Member

The only reason I used Visual Studio 2017 for that build in #3941 is that it was the latest version for which Visual Studio solution files existed back then. Not sure if switching it to CMake would make much sense as we already have a lot of CMake builds. I'd rather switch it to VS 2013, which is also the oldest version supported by Appveyor. Otherwise, we have no Visual Studio solution build at all in CI, right?

Or did I misunderstand something and the plan was to turn it into something special?

@vszakats

vszakats commented Apr 9, 2024

Copy link
Copy Markdown
Member

An option to keep this job useful is moving it to VC 12 (= Visual Studio 2013) (from 14.10 aka Visual Studio 2017). This compiler version isn't tested at the moment and generate.bat continues to support it. It's available in the "Visual Studio 2015" AppVeyor image: https://www.appveyor.com/docs/windows-images-software/#visual-studio-2013

Here's a translation table for the confusing MSVC version numbering schemes:

Compiler                                _MSC_VER value
--------                                --------------
C Compiler version 6.0                  600
C/C++ compiler version 7.0              700
Visual C++, Windows, version 1.0        800
Visual C++, 32-bit, version 1.0         800
Visual C++, Windows, version 2.0        900
Visual C++, 32-bit, version 2.x         900
Visual C++, 32-bit, version 4.0         1000
Visual C++, 32-bit, version 5.0         1100
Visual C++, 32-bit, version 6.0         1200
Visual Studio .NET (2002), version 7.0  1300
Visual Studio .NET 2003, version 7.1    1310
Visual Studio 2005, version 8.0         1400
Visual Studio 2008, version 9.0         1500
Visual Studio 2010, version 10.0        1600
Visual Studio 2012, version 11.0        1700
Visual Studio 2013, version 12.0        1800
Visual Studio 2015, version 14.0        1900
Visual Studio 2017, version 14.1*       1910-1919
Visual Studio 2019, version 14.2*       1920-1929
Visual Studio 2022, version 14.3*       1930-19??

@vszakats

vszakats commented Apr 9, 2024

Copy link
Copy Markdown
Member

Tested the VC12 approach here, with success:
https://ci.appveyor.com/project/curlorg/curl/builds/49581291/job/427yrxk4qmquqvv2

Patch:

--- a/appveyor.yml
+++ b/appveyor.yml
@@ -230,12 +230,12 @@ environment:
       TESTING: 'OFF'
       ENABLE_UNICODE: 'yes'
     # generated VisualStudioSolution-based builds
-    - job_name: 'VisualStudioSolution, VS2017, Debug, x86, Schannel, Build-only'
-      APPVEYOR_BUILD_WORKER_IMAGE: 'Visual Studio 2017'
+    - job_name: 'VisualStudioSolution, VS2013, Debug, x86, Schannel, Build-only'
+      APPVEYOR_BUILD_WORKER_IMAGE: 'Visual Studio 2015'
       BUILD_SYSTEM: VisualStudioSolution
       PRJ_CFG: 'DLL Debug - DLL Windows SSPI - DLL WinIDN'
       TESTING: 'OFF'
-      VC_VERSION: VC14.10
+      VC_VERSION: VC12
     # autotools-based builds (NOT mingw cross-compiling, but msys2 native)
     - job_name: 'autotools, msys2, Debug, x86_64, no Proxy, no SSL'
       APPVEYOR_BUILD_WORKER_IMAGE: 'Visual Studio 2017'

@github-actions github-actions Bot added the CI Continuous Integration label Apr 9, 2024
@bagder bagder closed this in 6389ba8 Apr 10, 2024
@bagder
bagder deleted the bagder/drop-new-msvc-proj branch April 10, 2024 05:57
@bagder

bagder commented Apr 10, 2024

Copy link
Copy Markdown
Member Author

Thanks a lot @jay and @vszakats !

@bagder bagder mentioned this pull request Apr 11, 2024
3 tasks
vszakats added a commit to vszakats/curl that referenced this pull request Jan 26, 2025
vszakats added a commit that referenced this pull request Jan 27, 2025
- `.gitignore`: delete, dedupe and move rules upwards.
  Ref: 6389ba8 #13311
- `.gitignore`: fix generated test sources.
  Follow-up to 71cf0d1 #14772
- `.gitignore`: replace exe listings with a wildcard.
- lib: move `setup-*.h` from `EXTRA_DIST` to `CURL_HFILES`.
- `makedebug.bat`: uppercase an argument to match docs.
- GHA/non-native: delete stray env.
  Follow-up to 12a6de2 #16043
- sort source lists.

Closes #16093
pps83 pushed a commit to pps83/curl that referenced this pull request Apr 26, 2025
- `.gitignore`: delete, dedupe and move rules upwards.
  Ref: 6389ba8 curl#13311
- `.gitignore`: fix generated test sources.
  Follow-up to 71cf0d1 curl#14772
- `.gitignore`: replace exe listings with a wildcard.
- lib: move `setup-*.h` from `EXTRA_DIST` to `CURL_HFILES`.
- `makedebug.bat`: uppercase an argument to match docs.
- GHA/non-native: delete stray env.
  Follow-up to 12a6de2 curl#16043
- sort source lists.

Closes curl#16093
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build CI Continuous Integration dist Windows Windows-specific

Development

Successfully merging this pull request may close these issues.

4 participants