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

[René Berber]

On 5/23/2018 1:13 AM, Daniel Stenberg wrote:

[snip]
> 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.

Exactly the main point.  Porting (to Windows in this case) is the main
issue, building environments is secondary and, since many work fine, not
even an important issue.

Like many others have said for their case... I use MXE, which is a
cross-build environment that usually targets Windows, their maintainers
(and users) keep track of what works, and if not, what's needed, usually
small patches.  If one of those patches did change curl's source, it
will be sent upstream (trying to keep things as clean as possible in MXE
itself).

So this is a use case that uses Unix/Linux tools (also can be used under
Cygwin/Windows, or OSX) and gets results.  Currently for curl it uses
the configure way, but it can use cmake (and it does for other
packages).  Side note: it has the advantage that you can further
customize your build, I use my own curl+cares recipe.
-- 
R. Berber
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

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

[Daniel Stenberg]

On Wed, 23 May 2018, Sergei Nikulov wrote:


 message(WARNING "the curl cmake build system is poorly maintained.


We already tried multiple times to remove this message, but Daniel still 
objects those changes :)


But do you consider that line to be wrong ?

I think our 9 open cmake issues basically prove me right. And its not like 
these nine issues are a new problem that just appeared. Our cmake issues often 
take a long time to get fixed in our project.


The cmake build works perfectly for a whole bunch of users and that's fine and 
good, but there's no doubt in my mind that if you run into problems with it 
you're up for a rougher ride than with some of the other build options we 
have. Plus the fact that the cmake build is far from as feature-complete as 
the configure build is.


--

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

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

[Sergei Nikulov]

ср, 23 мая 2018 г. в 11:49, Richard Alcock :

> On 23 May 2018 at 07:25, David Weisgerber 
wrote:
> > 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.

> The big thing that put me off using CMake was this:

>  message(WARNING "the curl cmake build system is poorly maintained.
> Be aware")

> (from
https://github.com/curl/curl/blob/09d16af49a07af14dd635e23cdd6a0d287e54e54/CMakeLists.txt#L50
)


We already tried multiple times to remove this message, but Daniel still
objects those changes :)
That's why email with this subject appears here.

-- 
Best Regards,
Sergei Nikulov

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

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

[Richard Alcock]

On 23 May 2018 at 07:25, David Weisgerber  wrote:
> 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.

The big thing that put me off using CMake was this:

message(WARNING "the curl cmake build system is poorly maintained.
Be aware")

(from 
https://github.com/curl/curl/blob/09d16af49a07af14dd635e23cdd6a0d287e54e54/CMakeLists.txt#L50)


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

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

[Sergei Nikulov]

ср, 23 мая 2018 г. в 8:56, 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.

Just FYI, CMake able to generate 1,3,5,6
https://cmake.org/cmake/help/v3.0/manual/cmake-generators.7.html
So you can use nmake after the cmake -G"NMake Makefiles" invocation.

-- 
Best Regards,
Sergei Nikulov

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

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

[David Weisgerber]

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

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

[Daniel Stenberg]

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

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

[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

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

[Daniel Stenberg]

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


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.


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

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

[Kees Dekker]

> Any takers?
> 
> I do a lot of stuff in this project. I merge something like 80% of all commits
> and I (currently) author around 60% of all commits. I do this because I think
> it's fun and I enjoy doing it. And I feel that know the technologies involved.
> 
> There are however two specific areas that are *definately* not my areas of
> expertise and I sense that our project suffers a bit because I don't easily
> merge patches done within those areas and there's an unclear situation on
> how
> to go about and get things done there.
> 
> I'm talking about cmake and Windows.
> 

Hi Daniel,

I understand the described need, but I simply don't have time (and support by 
management).

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

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.

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. If it is 
possible to limit the list of support Windows versions, and e.g. say: if you 
use mingw, use native Linux instead (not sure whether that is possible), or 
anything else, then the wide range of Windows variations may get reduced. 
Actually, full support of Windows (due to the support of very old stuff) is 
almost as difficult as support all *NIX flavors. As *NIX world has a much 
bigger 'common sense in keeping compatible' (compared to Windows), you may like 
to consider this. Otherwise, contribution of Windows people is (I guess) too 
much work.

Just my 2 cents. I hope that these are useful to you.

Regards,
Kees

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