Fix missing whitespace in patches

[meator]

Such patches may be technically invalid. These errors also mess with git patch-id, which is undesirable.

[Biswa96]

Would you be able to provide any examples or scenarios where the patches have caused such issues?

[meator]

git patch-id produces three hashes for patches/core/0009-Don-t-use-the-internal-glibc-header-sys-cdefs.h.patch:

3c75668ae2bc2962bbaf4f597fc347c50cbf3618 49a3dad208220b35ca7d81b7ea7f053801ada9dd
054391c5b23087109d0df6bf038a2a4c227bec9a 0000000000000000000000000000000000000000
760645491822343d3f93af4f7225536b2a16368c 0000000000000000000000000000000000000000

This is nonsense. This behavior is caused by patches/core/0009-Don-t-use-the-internal-glibc-header-sys-cdefs.h.patch being invalid (it is missing whitespace added by this PR, which makes it think that there are multiple commits/patches in this file).

All patches touched by this PR produce a different patch-id when applied. That shouldn't happen, especially when --stable is provided.

[meator]

I am doing a lot of work on android-tools on my fork (I rewrote its build system in Meson to add builtin Windows support and to fix #174, I planned to make an issue/create a discussion once I'm finished).

I may be able to fix the CI failures, because I've added extra patches to fix various things in nmeum/android-tools.

[meator]

I haven't yet encountered this issue. I do not use such new clang++ which suffers from it.

Issue: fmtlib/fmt#4396

Commit which fixes it: fmtlib/fmt@6797f0c (or https://android.googlesource.com/platform/external/fmtlib.git/+/6797f0c39a4ef13061cbc3bb850c35af7428fdc4%5E%21/).

Backporting this to fmtlib platform-tools-35.0.2 (current version of fmtlib vendored project) is not trivial. I'll see what I can do.

[meator]

6797f0c39a4ef13061cbc3bb850c35af7428fdc4 is not yet in any tagged version of https://android.googlesource.com/platform/external/fmtlib.git/ (more specifically sdk-release).

An alternative solution would be to switch from Google fmtlib to official one and update it. I already do something similar in my fork, since I do not know whether Google adds any worthwhile additions to fmt in comparison to the official source.

[meator]

Should I fix the issue to make this PR mergeable? This PR did not cause the failed CI. Users who could suffer from this can always use a system libfmt.

[salvogiangri]

Omitting -DANDROID_TOOLS_USE_BUNDLED_FMT=ON is enough for me to get around this issue in my end. If that commit fixes compiling with newer Clang versions I think it can be temporarily added inside patches/fmtlib along with all the other existing patches, I did something similar in my own fork to get around #158 (UN1CA@c00b6e1).

6797f0c39a4ef13061cbc3bb850c35af7428fdc4 is not yet in any tagged version of https://android.googlesource.com/platform/external/fmtlib.git/ (more specifically sdk-release).

I could find the commit you mentioned in android-16.0.0_r1, which probably means it is part of platform-tools 36.0.0. However Google still didn't push the tags for some reason...

[meator]

it can be temporarily added inside patches/fmtlib along with all the other existing patches

You mean all existing patches in general? Because there are currently no patches for fmtlib.

As I said, backporting the commit to platform-tools-35.0.2 is nontrivial.

I could find the commit you mentioned in android-16.0.0_r1, which probably means it is part of platform-tools 36.0.0. However Google still didn't push the tags for some reason...

Even if this tag existed, would it be wise to use a 36.0.0 fmtlib inside 35.0.2 android-tools? I'm sure it'll be compatible, but it could make a mess in the vendor project pinning/versioning.

[salvogiangri]

You mean all existing patches in general? Because there are currently no patches for fmtlib.

Yes that's what I meant.

Even if this tag existed, would it be wise to use a 36.0.0 fmtlib inside 35.0.2 android-tools? I'm sure it'll be compatible, but it could make a mess in the vendor project pinning/versioning.

Yeah there's no point on upstreaming only that, I was just pointing out that a future update to the newest tag project-wide will definitely address this, assuming Google will finally decide to push the goodies🙄.

[meator]

Hey, is anything blocking this PR?

[Biswa96]

Oh, I thought you were working on the build issues in this PR.

[meator]

That would probably be more appropriate in a new PR. Thanks for merging!