Some work for the OS/400.

[monnerat]

Add new definitions to the ILE/RPG binding.
Update supported protols list in README file.
Rework OS/400 configuration file.

[monnerat]

The key to that particular reason is that this file is generated at build time - at the moment the build happens. It is not stored in git.
For the config files we store in git it is better to keep them minimal, and one easy way to do that is to remove all #undefs.

I understand very well and am aware of it.
But let me expose a little scenario:

1. we have a minimal OS400 config file.
2. In the few next months, some developer adds some definition. It mainly focuses on configure.ac and CMakeLists.txt. But he skips the config-*.h files because he does not know about these platforms without autotools.
3. Some time later, an OS400 maintainer wants to check config and keep it up to date: since the minimal file is not self-documenting, it is hard to know then why a #undef is present is the newly generated curl_config.h.in but not in config-os400.h: should it really not be defined or is it new? The tedious and redundant job here is to recheck things that are not new.

I can suggest a solution that should satisfy everyone:

1. For #undef's that has been already taken into account, only list their names in a comment.
2. Keep the #define's sorted by name.

This will shorten the file, although not as minimal and retain maintenance help info.
OK for this?

[vszakats]

1. we have a minimal OS400 config file.
2. In the few next months, some developer adds some definition. It mainly focuses on configure.ac and CMakeLists.txt. But he skips the config-*.h files because he does not know about these platforms without autotools.
3. Some time later, an OS400 maintainer wants to check config and keep it up to date: since the minimal file is not self-documenting, it is hard to know then why a #undef is present is the newly generated curl_config.h.in but not in config-os400.h: should it really not be defined or is it new? The tedious and redundant job here is to recheck things that are not new.

Is there a reason diffing curl_config-cmake.h.in between
the last verified version and the current one doesn't work?

It's the canonical source of truth where these settings get
added and deleted, whenever it happens. It's unlikely to
disappear.

The diff can be limited to cmakedefine lines and sorted,
for a short diff:

$ grep cmakedefine lib/curl_config-cmake.h.in | sed 's/cmake//g' | sort

I can suggest a solution that should satisfy everyone:

1. For #undef's that has been already taken into account, only list their names in a comment.

I still don't see why a second inventory of settings would be
a benefit. My preference would be to not add any #undefs.

2. Keep the #define's sorted by name.

Sorted seems fine, but since this is difficult to enforce, I'm
not sure how much it helps. When diffing, it'd probably make
sense to sort dynamically anyway, just in case.

[monnerat]

Is there a reason diffing curl_config-cmake.h.in between
the last verified version and the current one doesn't work?

Diff always work, but it should stay usable, I mean readable.

I still don't see why a second inventory of settings would be
a benefit. My preference would be to not add any #undefs.

It's not an inventory of current curl-wide settings, but an inventory of OS/400 settings at the time of last review/update, including confirmed negative defines.

Sorted seems fine, but since this is difficult to enforce,

Not really, if the file shortens.
The reason for sort is curl_config.h.in is produced as such and this will render the side-by-side diff more readable.

[vszakats]

Is there a reason diffing curl_config-cmake.h.in between
the last verified version and the current one doesn't work?

Diff always work, but it should stay usable, I mean readable.

I pushed a script to that effect in #20713.

edit: this one-liner looks simpler and more informative:

$ git log -pw --follow master...curl-8_15_0 lib/curl_config-cmake.h.in

(can be tweaked for less/more information. A diff between
this file in two release tarballs is another solution.)

It's not an inventory of current curl-wide settings, but an inventory of OS/400 settings at the time of last review/update, including confirmed negative defines.

An inventory nevertheless to carry, maintain, and ignore every
time a grep hits it.

Sorted seems fine, but since this is difficult to enforce,

Not really, if the file shortens. The reason for sort is curl_config.h.in is produced as such and this will render the side-by-side diff more readable.

It's what I meant by sorting at the time of diffing. Since the
order isn't enforced and may not remain accurate, it needs
to be done at that time anyway. ...how does sorting make
the file shorter?