RE: Assigning "sub maintainers" for Windows and cmake!
Date: Tue, 22 May 2018 16:00:43 +0200 (CEST)
On Tue, 22 May 2018, Kees Dekker wrote:
> It also does not help that there are (correct me if I'm wrong) at least 3
> methods in building cURL on Windows:
> 1. solution files
> 2. cmake
> 3. nmake
4. configure (msys/mingw)
5. Borland makefiles
6. mingw makefiles
> I understand that 'everybody is liking his own preferred method' (in my case
> #3), but it also makes that the few maintainers/contributors available only
> check one or probably 2 out of 3 available methods. That is encouraging
> inefficiency in my opinion. I know, that if someone decides to flavor one of
> these 3, I may also suffer from dropping the other two.
My hope was always that one of them would eventually grow up to be "the
winner", but that simply never happened. And it's not likely to actually ever
happen. I actually don't think the build system plethora is such a big
problem, they mostly work.
If we would drop build systems from the list above, it would make the most
sense to drop 1, 3, 5 and 6 I think, leaving configure and cmake. I just don't
think we would make many users happy today or tomorrow if we'd make that
According to the currently ongoing curl user survey, configure and cmake are
clearly the most commonly used build systems and if we don't count "something
else", the winbuild setup is on a 3rd place.
Ultimately though, most of our Windows problems are not about fixing one of
the builds but tend to be about generic concepts that apply to whatever build
system that's used.
> I addition: remaining to support Windows from archaic to up-to-date Windows
> and Visual Studio versions, including mingw and other flavors, means that
> 'not solely support' is wanted, but 'broad knowledge' over a wide range.
I wouldn't call anyone truly "knowledgable in Windows" if said person is not
somewhat oriented in the different versions that exist and are in use. But
nobody was an expert on anything from day one; an interest to do the right
thing is much more important than knowing everything.
I'm partly posting this mail to make the community aware of where we possibly
are as weakest as a project. A "status update" about what I think I see from
my viewpoint over in this corner.
Worst case, we just continue like before. That's not bad. But could be better.
-- / daniel.haxx.se ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2018-05-22