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

cmake: deprecate winbuild, add migration guide from legacy build methods #15920

Closed
wants to merge 24 commits into from

Conversation

vszakats
Copy link
Member

@vszakats vszakats commented Jan 6, 2025

We recommend migrating to CMake from winbuild and Visual Studio project
files. winbuild is deprecated and will be dropped in September 2025.

CMake supports all the features and options, with new ones added
promptly. It supports out-of-tree, unity and documentation builds.

  • deprecate winbuild method in favour of CMake by September 2025.
  • add migration guide from winbuild to CMake.
  • add migration guide from Visual Studio Project Files to CMake.
  • add deprecation message to winbuild.
    Need to ack with WINBUILD_ACKNOWLEDGE_DEPRECATED=yes
    Authored-by: Jay Satiro
  • mention CMAKE_BUILD_TYPE option in INSTALL-CMAKE.
  • document missing SSH_PATH winbuild option.

@bagder
Copy link
Member

bagder commented Jan 7, 2025

Should we consider starting the process of deprecating the winbuild directory?

@jay
Copy link
Member

jay commented Jan 7, 2025

Should we consider starting the process of deprecating the winbuild directory?

IMO no but do you mean deprecate to remove or make legacy to suggest cmake in the readme? It's fast with the native tools and if more options are needed the user can choose cmake or autotools.

@bagder
Copy link
Member

bagder commented Jan 7, 2025

Because it is an additional build system to maintain, while all the options are also available with cmake.

In the 2024 survey, only 12 people said they use the winbuild system. 84 said cmake and 142 checked configure.

@vszakats
Copy link
Member Author

vszakats commented Jan 7, 2025

CMake builds with Unity enabled should be faster than a winbuild native build.
Have you tried it @jay? (with -DCMAKE_UNITY_BUILD=ON)

It's possible to shave more time off by disabling docs/manuals (which are not
built with winbuild), with these options:

-DBUILD_LIBCURL_DOCS=OFF -DBUILD_MISC_DOCS=OFF -DENABLE_CURL_MANUAL=OFF

(This is also the default if the env misses Perl.)

On AppVeyor CI the configure stage is super slow with VC2015/2017 for some
reason. (I have plans to pre-fill some remaining detections (type sizes) to make
this faster for Windows builds.)

The configure step typically caches most of the things after the initial run, so
this is likely much less of an issue locally.

Even with configure stage running, on AppVeyor, newer MSVC build times are
comparable to winbuild:
https://ci.appveyor.com/project/curlorg/curl/builds/51277871
(One CMake job was even faster than winbuild in this particular run)
(edit: that was with VS2022, not 2017)

@vszakats
Copy link
Member Author

vszakats commented Jan 7, 2025

CMake is mature enough to take over the load from winbuild builds.
Deprecating them seems like a good idea to me.

I'm happy to hear of issues that may remain in CMake. CMake's
advantage is that it has all the features, with new ones added promptly.
It's also well tested and documented, and build basics are the same
in curl as in other projects. It also supports generating NMake files.

I made some commits fixing a few warnings when compiled with
CMake + older MSVC versions, and added all missing versions to
AppVeyor.

Regarding performance, VS2015 and VS2017 seem to suffer from
extreme slowness while detecting the short list of features. I don't
know why that it and it's certainly a non-issue with winbuild.
The question is if this is CI specific and/or something that can be
offset locally by Unity builds and the other advantages of CMake.
Bearing in mind that feature detection does only run when initializing
a build (as said above.)

CMake jobs with all supported MSVC versions:
https://ci.appveyor.com/project/curlorg/curl/builds/51279379

edit: without the ability to test these locally it's hard to day, but
speculating some more here:
#15922 (comment)

@vszakats
Copy link
Member Author

vszakats commented Jan 7, 2025

Added a deprecations message. Let me know if it's OK, or if you have any suggestion.

@vszakats vszakats requested a review from bagder January 7, 2025 22:22
@jay
Copy link
Member

jay commented Jan 8, 2025

I built curl this afternoon using Visual Studio and the build time for me was comparable, about 30 seconds for winbuild and CMake as long as manual and docs are disabled. I'm pretty sure I didn't use unity mode. I suspect it's a little more than 12 people using winbuild but I see the point given all the work done on cmake. For old systems that use VS2010-2013 without cmake there are still project files in projects/ even if very few people may use them. And I don't know who is using VS2008, if anyone.

I suggest a deprecation notice so that users have time to prepare, for example what do you think of this notice that would require acknowledgement of deprecation in one year:

diff --git a/winbuild/Makefile.vc b/winbuild/Makefile.vc
index bc20d05..079246f 100644
--- a/winbuild/Makefile.vc
+++ b/winbuild/Makefile.vc
@@ -22,6 +22,21 @@
 #
 #***************************************************************************
 
+!MESSAGE
+!MESSAGE WARNING:
+!MESSAGE
+!MESSAGE The winbuild build system is deprecated and will be removed in 2026
+!MESSAGE in favor of the CMake build system.
+!MESSAGE
+!MESSAGE Please see docs/INSTALL-CMAKE.md : "Migrating from winbuild builds"
+!MESSAGE
+!MESSAGE To use the winbuild build system you must acknowledge this warning by
+!MESSAGE setting command line option WINBUILD_ACKNOWLEDGE_DEPRECATED=yes
+!MESSAGE
+!IF "$(WINBUILD_ACKNOWLEDGE_DEPRECATED)"!="yes"
+!ERROR The user must acknowledge the deprecation warning to continue.
+!ENDIF
+
 !IF "$(MODE)"=="static"
 TARGET = $(LIB_NAME_STATIC)
 AS_DLL = false

@bagder
Copy link
Member

bagder commented Jan 8, 2025

Added a deprecations message. Let me know if it's OK, or if you have any suggestion.

Add a section to docs/DEPRECATE.md as well with an exact date when the files are dropped.

@vszakats vszakats changed the title cmake: add migration guide from winbuild cmake: deprecate winbuild, add migration guide from it Jan 8, 2025
@vszakats
Copy link
Member Author

vszakats commented Jan 8, 2025

Made a few migration guide adjustments, added the warning/ack,
an entry in DEPRECATE.md. Set the date to September 2025.
Let me know if this is fine.

I also added a section for migrating from the VC10/11/12 IDE Project files.
Would it be sensible to deprecate them too?

edit: PR to drop VS2008 from CI: #15934 (I haven't found where we
document the minimum required VS version. The codebase also
has some amount of mention for earlier VS versions via _MSC_VER.)

@vszakats vszakats changed the title cmake: deprecate winbuild, add migration guide from it cmake: deprecate winbuild, add migration guide from legacy methods Jan 8, 2025
@vszakats vszakats changed the title cmake: deprecate winbuild, add migration guide from legacy methods cmake: deprecate winbuild, add migration guide from legacy build methods Jan 8, 2025
@github-actions github-actions bot added the CI Continuous Integration label Jan 8, 2025
@MonkeybreadSoftware
Copy link
Contributor

Well, I still use winbuild.
I can try to see if I can switch my build scripts over to cmake and see if I miss an option for cmake.

@jay
Copy link
Member

jay commented Jan 8, 2025

I also added a section for migrating from the VC10/11/12 IDE Project files.

The project file generator is left for systems too old to use cmake or they are using a recent version of cmake with an old version of Visual Studio and can't generate project files for that version. I still use it to switch back and forth between configurations. We limited it in a different thread to 2010 - 2013 because at the time I think those were the versions scheduled to be removed from CMake's project file generator. If a more recent version of Visual Studio is available it may be possible to use CMake to set the toolset to target 2010-2013.

@vszakats
Copy link
Member Author

vszakats commented Jan 8, 2025

I also added a section for migrating from the VC10/11/12 IDE Project files.

The project file generator is left for systems too old to use cmake or they are using a recent version of cmake with an old version of Visual Studio and can't generate project files for that version. I still use it to switch back and forth between configurations. We limited it in a different thread to 2010 - 2013 because at the time I think those were the versions scheduled to be removed from CMake's project file generator. If a more recent version of Visual Studio is available it may be possible to use CMake to set the toolset to target 2010-2013.

Ah okay, I get it.

The CMake manual suggests it's also possible to build VS10, 11 and 12
by using -G "NMake Makefiles". Have you tried it?

It also seems possible to install an older cmake binary (to an alternative path)
that still has support for these VC versions, from here: https://cmake.org/files/
E.g. this is compatible with all three: https://cmake.org/files/v3.24/cmake-3.24.4-windows-x86_64.zip

I think it's a matter of calling that specific cmake.exe with a full path.

Do you think that could work?

FTR generator removal versions/dates:
Visual Studio 10 2010 in CMake 3.25 (2022-11-30),
Visual Studio 11 2012 in CMake 3.28 (2023-12-24),
Visual Studio 12 2013 in CMake 3.31 (2024-11-21).

@jay
Copy link
Member

jay commented Jan 9, 2025

What I mean is cmake won't generate the projects anymore so you can't open it in the ide. Yes old versions of cmake probably work to generate projects. Also this is what I mean by switching configurations,

Capture

@vszakats
Copy link
Member Author

vszakats commented Jan 9, 2025

What I mean is cmake won't generate the projects anymore so you can't open it in the ide. Yes old versions of cmake probably work to generate projects. Also this is what I mean by switching configurations,

Right, so NMake Makefiles isn't practical. But would using an older CMake version work in your setup for example? The CI is using this method, though perhaps the question is if the IDE can be told to use a specific, older CMake?

@jay
Copy link
Member

jay commented Jan 9, 2025

I'm not saying it can't be done in cmake, I'm sure it can with an old version. However the legacy project generator works for older systems without separate build tools installed like cmake. The configuration switching I find useful but to be fair that's something probably only I do since I work on the project.

@vszakats vszakats closed this in fdc588d Jan 10, 2025
@vszakats
Copy link
Member Author

Thanks for the help, feedback and reviews to all. This is merged now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

Successfully merging this pull request may close these issues.

4 participants