Remove cfg-if dependency.

[m-ou-se]

This removes the cfg-if dependency.

It was only used in one place with a single if-else, which can easily be replaced.

Before:

cfg_if::cfg_if! {
    if #[cfg(..)] {
        ..
    } else {
        ..
    }
}

After:

#[cfg(..)]
{
    ..
}
#[cfg(not(..))]
{
    ..
}

[m-ou-se]

This reduces the number of dependencies of a no-default-features build from 8 to 7:

1. libc
2. memoffset
3. autocfg
4. once_cell
5. pyo3-ffi
6. pyo3-build-config
7. target-lexicon

[m-ou-se]

If PyO3 ever bumps its MSRV to 1.70, once_cell can be removed in favor of std::sync::{OnceLock, LazyLock}.

Similarly, if PyO3 ever bumps its MSRV to 1.77, memoffset (and therefore autocfg) can be removed in favor of std::mem::offset_of.

At which point the base pyo3 build will only have 4 dependencies. :)

[davidhewitt]

Thanks, yep always keen to minimize dependencies here! I had been meaning to drop that cfg_if code for a while but never quite got around to it 😅

[m-ou-se]

always keen to minimize dependencies here!

Fwiw, if you want to go even further, you could maybe also consider getting rid of libc. In pyo3 it is mainly used for size_t, ssize_t, intptr_t and uintptr_t, but those are just usize and isize on all platforms. wchar_t is a bit annoying, but the only real problem might be libc::FILE. There might be some workaround for that.

Probably not worth it though. :)

[davidhewitt]

always keen to minimize dependencies here!

Fwiw, if you want to go even further, you could maybe also consider getting rid of libc. In pyo3 it is mainly used for size_t, ssize_t, intptr_t and uintptr_t, but those are just usize and isize on all platforms. wchar_t is a bit annoying, but the only real problem might be libc::FILE. There might be some workaround for that.

Probably not worth it though. :)

Agreed, I had considered similar but it seems fine to keep it and let libc get those core definitions right on all platforms!

[alex]

Of course, if std/core were to get these types, we could use those :-)

[m-ou-se]

The size and intptr types, sure, that seems likely to happen. Not sure about wchar_t.. maybe. FILE, however, seems unlikely.

[alex]

Perhaps if the integer types were in std we could just drop the FILE-using functions, I wonder if anyone uses them. (They basically all have some alternatives.)