curl / Mailing Lists / curl-library / Single Mail


RE: Assigning "sub maintainers" for Windows and cmake!

From: Kees Dekker <>
Date: Wed, 23 May 2018 05:53:34 +0000

> > 1. solution files
> > 2. cmake
> > 3. nmake
> and...
> 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
> announcement.

I'm both working on *NIX and Windows, and from that point of view I understand your preference of dropping 1,3,5,6.
However, from Windows point of view, 1,3 are THE native visual studio ones. That native ones are usually preferred by Windows developers
(but again: correct me if I'm wrong) as using/building cURL is not an end in itself. In most cases, curl is a part of a larger whole.
Windows developers are using curl as part of whatever (IMO usually). For that reason, the build procedure of curl need to
match or incorporated in some way with a larger whole, i.e. the code base of the adopting party. If a adopting party does not use
none of the 'non-visual-studio' methods, the others make not much sense. Of course, if someone uses 'one of the others', they can
say the same for the visual studio-based methods.

I think - but that is a wild guess of me - the *NIX look-alikes on Windows systems are being used because their organization forces
to use a Windows system (laptop or desktop) but the end-users love the UNIX world, and thus use something like mingw/Cygwin (=4,6).
Their actual need is a Linux system, but that one does not offer Microsoft office. Borland is something from very long time ago (30+ years) for me.

I will try to contribute where I can, and really prefer 1 or 3 (we are now using 3 and calling nmake from within another project file).

Received on 2018-05-23