Supporting builds with static dependencies and keeping that working over time is some serious pain inflicting activity.

Thanks for your report. There has been changes around this in the latest master.

Can you give it a try to see how it behaves in this scenario?

Check master (4a382f4)
Same error, and with
-DBUILD_SHARED_LIBS=OFF -DBUILD_STATIC_LIBS=ON -DUSE_LIBIDN2=ON
and with adding
-DCURL_USE_PKGCONFIG=ON

Thanks for testing!

Would you mind posting all the LIBIDN2_STATIC_* variables that got detected in your env?

it from CMakeCache
LIBIDN2_STATIC_CFLAGS:INTERNAL=-I/home/nemos/packages/win64/libidn2-2.3.7/include
LIBIDN2_STATIC_CFLAGS_I:INTERNAL=
LIBIDN2_STATIC_CFLAGS_OTHER:INTERNAL=
LIBIDN2_STATIC_INCLUDE_DIRS:INTERNAL=/home/nemos/packages/win64/libidn2-2.3.7/include
LIBIDN2_STATIC_LDFLAGS:INTERNAL=-L/home/nemos/packages/win64/libidn2-2.3.7/lib;-lidn2;-L/home/nemos/packages/win64/libiconv-1.17/lib;-liconv;-L/home/nemos/packages/win64/libunistring-1.2/lib;-lunistring
LIBIDN2_STATIC_LDFLAGS_OTHER:INTERNAL=
LIBIDN2_STATIC_LIBDIR:INTERNAL=
LIBIDN2_STATIC_LIBRARIES:INTERNAL=idn2;iconv;unistring
LIBIDN2_STATIC_LIBRARY_DIRS:INTERNAL=/home/nemos/packages/win64/libidn2-2.3.7/lib;/home/nemos/packages/win64/libiconv-1.17/lib;/home/nemos/packages/win64/libunistring-1.2/lib
LIBIDN2_STATIC_LIBS:INTERNAL=
LIBIDN2_STATIC_LIBS_L:INTERNAL=
LIBIDN2_STATIC_LIBS_OTHER:INTERNAL=
LIBIDN2_STATIC_LIBS_PATHS:INTERNAL=

Thanks, it means also *_LIBRARIES and *_LIBRARY_DIRS are populated. These are used by curl's CMake, though never the static ones.

It's hard to say on what conditions shall a project pick up the *_STATIC* variants of these variables instead of the default ones. Or, ideally, is there a built-in CMake option to control this behavior? to avoid reinventing the wheel in a project-specific, and perhaps wrong way.

The general question is: how to select static vs. shared libs for specific targets and their specific dependencies. Since this would be too fiddly for most practical use-case: What options to offer that satisfy most static vs shared use-cases? (that also works smoothly across the supported build-cases)

Till these questions get answers, I suggest feeding the build with the necessary libs and paths manually: LIBIDN2_LIBRARY/LIBIDN_INCLUDE_DIR, and/or CMAKE_EXE_LINKER_FLAGS/CMAKE_SHARED_LINKER_FLAGS/CMAKE_C_FLAGS.

As @bagder mentioned, static builds are generally a pain, and especially to automate them across all build cases.

As i understand there are no billt-in CMake option for that. Only what i found similar this.
If there are no way to automatic decide what type of lib to use, may be add some cmake option to control it from outside.

Yes, one option is to let the curl build know whether to use STATIC vs default for linking with curl and/or libcurl.

This will first bump into the issue that the recently introduced native pkg-config support is missing yet for most dependencies (libidn2 is one that got it already.) Before going there we will need to gather feedback and experience for the current ones.

The next question is how well would such option work across all dependencies when using their _STATIC values? Some fallouts may need individual tweaks or per-dependency control, and some people might want to control which specific dependency to stay with dynamic linking just out of preference.

Being pkg-config-specific still makes this feature a little odd and accidental. Perhaps there are ways to extend it to cmake-configs, for deps that offer a static/shared there. Thinking of <depname>::<libname>_static, or similar. But curl's CMake almost never uses this notation yet, and that is yet another sub-project.

TL;DR it can get complicated. Also difficult to test or guesstimate what happens when doing these.

Probably the best to do now is add this to the KNOWN_BUGS document.

Probably the best to do now is add this to the KNOWN_BUGS document.

I think it is more of a known restriction than a bug. It is the same for autotools: building with static dependencies is a Sisyphean task. Better leave that for the user to provide the dependencies.

I'm fine with this. Perhaps step by step it can be improved to a certain point, but to fully automate might indeed be an unrealistic goal.