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 [email protected]
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
