Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: functypes: recv/send argument definitions
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 26 Sep 2022 22:52:32 +0200 (CEST)
On Mon, 26 Sep 2022, Timothe Litt via curl-library wrote:
> This seems to be an unnecessary change; nothing is currently broken.
Broken vs non-broken is a binary divide, but the world has more nuances than
that. This is an area that can be improved. Like most areas can.
I take it you then think that the current code is better than the code I
suggest we replace it with? That's fine, but I find your arguments for this
rather weak:
> configure is almost by definition a library of "brute force" and ugly code.
I disagree.
> It's function is to avoid having builders edit .h and make files...so this
> PR is essentially a step backwards for whatever non-POSIX platforms the
> tests support.
You, someone who never contributes code or improvements for curl's configure
script, say this is "basically" a step backwards for some platforms you cannot
identify.
You say this to me, who edit the configure stuff weekly since decades and
consider this to be a change that simplifies our lives (as maintainers of the
build). The platforms that may get an initial road bump from this are mostly
the legacy niche ones that are barely used. I am usually the one who fixes
those build issues anyway so it's not like this is likely to hurt very many
others.
> If curl goes down this path, where does it stop?
What path are you referring to? The path of improving small things here and
there over time and improve the project little by little over the period of
several decades? I don't think that path stops at all.
> I think a fair argument could be made that all of configure/cmake could be
> replaced by "a few simple manual edits to a default config.h and Makefiles".
First I don't think how that is relevant here, but then I also don't think
that statement is true.
> With respect to performance: with configure I use a cache file (and
> recommend it - see --cache-file); this means that the test compiles aren't
> run except when the cache is rebuilt, which is rare.
Rare for some, less rare for others.
> I assume/hope that cmake has a similar facility.
It does.
Date: Mon, 26 Sep 2022 22:52:32 +0200 (CEST)
On Mon, 26 Sep 2022, Timothe Litt via curl-library wrote:
> This seems to be an unnecessary change; nothing is currently broken.
Broken vs non-broken is a binary divide, but the world has more nuances than
that. This is an area that can be improved. Like most areas can.
I take it you then think that the current code is better than the code I
suggest we replace it with? That's fine, but I find your arguments for this
rather weak:
> configure is almost by definition a library of "brute force" and ugly code.
I disagree.
> It's function is to avoid having builders edit .h and make files...so this
> PR is essentially a step backwards for whatever non-POSIX platforms the
> tests support.
You, someone who never contributes code or improvements for curl's configure
script, say this is "basically" a step backwards for some platforms you cannot
identify.
You say this to me, who edit the configure stuff weekly since decades and
consider this to be a change that simplifies our lives (as maintainers of the
build). The platforms that may get an initial road bump from this are mostly
the legacy niche ones that are barely used. I am usually the one who fixes
those build issues anyway so it's not like this is likely to hurt very many
others.
> If curl goes down this path, where does it stop?
What path are you referring to? The path of improving small things here and
there over time and improve the project little by little over the period of
several decades? I don't think that path stops at all.
> I think a fair argument could be made that all of configure/cmake could be
> replaced by "a few simple manual edits to a default config.h and Makefiles".
First I don't think how that is relevant here, but then I also don't think
that statement is true.
> With respect to performance: with configure I use a cache file (and
> recommend it - see --cache-file); this means that the test compiles aren't
> run except when the cache is rebuilt, which is rare.
Rare for some, less rare for others.
> I assume/hope that cmake has a similar facility.
It does.
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-26