Re: functypes: recv/send argument definitions

From: David Chapman via curl-library <curl-library_at_lists.haxx.se>
Date: Mon, 26 Sep 2022 11:55:11 -0700

On 9/26/2022 8:57 AM, Timothe Litt via curl-library wrote:
>
> On 26-Sep-22 11:14, Daniel Stenberg via curl-library wrote:
>> Hello!
>>
>> In my new PR[*], I am ripping out the old checks from configure and
>> cmake that
>> try to figure out what argument and return types recv and send want.
>> The new
>> system instead a) defaults to POSIX and b) offers functypes.h that
>> can provide
>> overrides for system that don't use the POSIX types.
>>
>> The reason for this is of course that the checks are very brute-force
>> and can
>> end up taking a long time and for all non-cmake/configure builds we
>> already
>> have the types provided anyway.
>>
>> This change removes crufty logic and simplifies the approach. I think
>> it feels
>> cleaner.
>>
>> <snip>
>>
>> PR: https://github.com/curl/curl/pull/9592
>>
> This seems to be an unnecessary change; nothing is currently broken.
>
> I'm not a cmake expert, but configure is almost by definition a
> library of "brute force" and ugly code.  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.
>

I'm neither a cmake expert nor a configure expert, but the curl 7.37.0
configure file is over 42,000 lines long, filled with arcane shell
script commands, some of which are duplicated.  It seems to be glued
together by some unknown outside force.  There's no way I could extend
it to cover a new platform if I needed to.

Quoting a random block from this file:

> # Transform confdefs.h into an awk script `defines.awk', embedded as
> # here-document in config.status, that substitutes the proper values into
> # config.h.in to produce config.h.
>
> # Create a delimiter string that does not exist in confdefs.h, to ease
> # handling of long lines.
> ac_delim='%!_!# '
> for ac_last_try in false false :; do
>   ac_tt=`sed -n "/$ac_delim/p" confdefs.h`
>   if test -z "$ac_tt"; then
>     break
>   elif $ac_last_try; then
>     as_fn_error $? "could not make $CONFIG_HEADERS" "$LINENO" 5
>   else
>     ac_delim="$ac_delim!$ac_delim _$ac_delim!! "
>   fi
> done

And this is a block with a comment - imagine trying to figure out how to
enhance it if there were no comments!

configure also writes files that show up by default as "modified - need
to commit" in sandboxes, so there is a risk of developers committing
these files and scrambling the work of teammates who may be on a
different platform.  To me, as a non-curl developer, configure has no
benefit.  Replacing it sounds like a good idea.

Last but not least, this won't run on Windows absent Cygwin or
equivalent.  Thus Windows users are forced to use pre-defined header
files, which can lose synchronization with the .in files.  CMake runs on
Windows.

> If curl goes down this path, where does it stop?  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". 
> (Though they'd evolve to be more than a few and messy...)  While I
> don't think you want to go all the way there, what test do you have in
> mind for similar proposals in the future?  Is there a standard for how
> much "brute force" or "ugliness" justifies creating work for some users?
>
I would assume that missing platforms would result in PRs (or at least
patch suggestions) from these users.

P.S.  Yes, I know that 7.37.0 is old, but the project which uses curl is
on hold right now.

-- 
     David Chapman      dcchapman_at_acm.org
     Chapman Consulting -- San Jose, CA
     EDA Software Developer, Expert Witness
     www.chapman-consulting-sj.com
     2018-2019 Chair, IEEE Consultants' Network of Silicon Valley
-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2022-09-26