Hi,
my company is working mainly on a MFC based product with Visual Studio
2010/2015. Some years ago we switched our build system to cmake and we now
generate Visual Studio files from cmake. For us this has a lot of benefits.
I also built the last libcurl versions with cmake (though it has some bugs)
because I think it is a lot easier and less error prone than using Visual
Studio files where you have to edit a lot in order to find the correct
libraries.
IMHO I would think about dropping some build systems in favor of cmake because
it works well for Windows and Linux builds and you have to maintain less.

Best regards,
David

Am Mittwoch, 23. Mai 2018, 07:53:34 CEST schrieb Kees Dekker:
> > > 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).
>
> -------------------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-05-23