On Wed, 23 May 2018, Kees Dekker wrote:

>> 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.

Sure, and that's exactly the line of reasoning everyone will have for why
their particular build system should remain. They use it, they know it and it
works for them.

I didn't seriously mean we would remove those.

My personal take on multiple build options is the same as supporting every OS
or architecture under the sun: let those who use that system fix it if there's
something wrong.

If we all polish and improve the code and scripts we use, things that are used
will grow better over time and things that aren't used... well if they aren't
used it doesn't matter too much if those areas fall behind a bit.

I'm more concerned about problems with code that is well used and that we get
issues and PRs filed about, but there's no maintainer around to give solid
advice, merge code etc for.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html