(The two red travis builds have been fixed on master in the mean time)

I'd appreciate a comment/review on this take from someone using the winbuild system!

Thanks Daniel. Can I submit new pull requests for the same file in the meanwhile?

And one thought from my side: if (in the theoretical case) no CFGSET was false then the clean rule is (after my change) the only rule that exists (unconditionally now) in in the MakefileBuild.vc, then if no target was specified upon calling nmake, the clean rule is called. This can be solved too of course. IMO it is quite strange to have targets that only exist under conditions. From my UNIX/Linux experience, this is very uncommon. I would prefer unconditional rules in any case. This is IMO normal practice. And checks should be done to check consistency of settings. Please share your thoughts....

Thanks Daniel. Can I submit new pull requests for the same file in the meanwhile?

Absolutely, and if it depends on this PR, just say so in the message.

it is quite strange to have targets that only exist under conditions

I would agree. But I don't want to step on toes in areas where I personally am not very familiar with (development on Windows) so I don't have any strong opinions here.

Please forgive my innocence: I continued in my own forked curl repo and made another change (commit + push). If I now create a new pull request, it also shows this pull request, however, this change is not related. How can I isolate a commits in a PR? I only want to create a PR for last commit (now, I also need to make more changes, that are dependent on this PR). Any help is welcome.

The problem is that you have your changes on the master branch. Just use separate branches for them.

@MarcelRaad: thanks for reply. I will try to do so (I'm knowing clearcase and its branch concepts, but I'm new to git). But as soon as a previous pull request is merged to the main branch, then I can continue making a new PR based on what then is or will be committed on the master branch?

I'm a lurker, but yea. Both changes (cleaning up the doco and making clean work) look useful. I also know (I think) where you are going with this and I'll be standing by tio test your changes as they come along as patches.

Thanks Rod: Now created PR: #2459.

You typically never commit anything to master yourself, see https://github.com/curl/curl/wiki/push-access-guidelines#do-not-work-in-your-local-master-branch. Instead, you pull from the remote master branch to yours to get the latest version and then commit directly to a new branch on top of that (GUIs typically let you do that in one step, I believe on the command line you have to first create the branch from the updated master and then commit.)

@MarcelRaad: Thanks for providing that information.

My initial landing page about how to contribute with cURL was https://curl.haxx.se/dev/contribute.html. That page describes 3 methods to make a contribution, but preferred the pull-request method. The information for a PR pointed to https://github.com/curl/curl/pulls (the overview of pull requests, where the help behind the 'new pull request button' points to https://help.github.com/articles/about-pull-requests/, a generic information page). After some struggling, I discovered that I had to make a fork and can create a PR from a fork. After some more struggling, I learned to use branches, to isolate changes. The URL mentioned by you provides even better information, but since I'm already busy, I first like to complete my current changes. Anyhow, it would be great if https://curl.haxx.se/dev/contribute.html would point to https://github.com/curl/curl/wiki/push-access-guidelines#do-not-work-in-your-local-master-branch instead of https://github.com/curl/curl/pulls.

Thanks!