Support Arm Mac

[kaycebasques]

Doxygen started recently releasing native Apple Silicon builds: doxygen/doxygen#10066 (comment)

Supporting this would solve the CI/CQ tryjob issues I described in #6 (comment)

[kaycebasques]

My first instinct is to split the mac platform into mac_arm and mac_intel:

doxygen_extension.version(
    sha256 = "...",
    # url needs to point to github action artifact download link for now
    url = "...",
    platform = "mac_arm"
)

doxygen_extension.version(
    sha256 = "...",
    version = "1.9.6",
    platform = "mac_intel"
)

@TendTo also suggested exposing executable here doxygen/doxygen#10066 (comment)

I think either would work for us but splitting the platforms into mac_arm and mac_intel would be a bit easier for me at the moment

[kaycebasques]

Side comment: macos-latest from GitHub Actions is apparently running Apple Silicon. Not sure why our tryjob is complaining about incorrect CPU type whereas rules_doxygen GitHub Actions using macos-latest are working https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources

[kaycebasques]

@TendTo re: your idea to expose executable, I think this is probably the best way for us to get unblocked short-term. Within the Pigweed repo we can provide different executables for Windows, Linux, macOS ARM, and macOS Intel.

Re: the rules_doxygen API it seems like another option may be needed, perhaps like this:

doxygen_extension.version(
    executable = "...",
    os = "mac",
    arch = "aarch64",
)

[kaycebasques]

I left a comment in doxygen/doxygen#10066 asking if they plan on releasing Doxygen 1.13.0 soon (and including the macOS ARM binary as part of the release). If they are, then it may be best to just wait for that. This issue is turning out to be complicated and I'm still figuring out what's the best course of action for Pigweed here.

[kaycebasques]

Doxygen confirmed that they don't have plans any time soon to provide official macOS ARM binary releases so I think that settles the issue. The path forward IMO is for rules_doxygen to allow users to provide their own per-platform executables

doxygen/doxygen#10066 (comment)

[TendTo]

Ok, I think we may be close. There are 2 new configurable platforms, linux-arm and mac-arm, and you can now provide an executable in the configuration. It should be a Label pointing to it, and you may need a @@ at the beginning if you are referring to the root module.

I also took advantage of this and also introduced a very easy to fix breaking change, (just rename doxygen_extension.version -> doxygen_extension.configuration).
Let me know if this would work for you.

[kaycebasques]

Great, thank you! I'll provide an update later today.

[kaycebasques]

I'm not sure if whether I'm holding something wrong or it's something on the rules_doxygen end but I'll share my progress.

In MODULE.bazel I've rigged up the prototype workflow to download/extract binaries:

http_archive(
    name = "doxygen_linux_gcc",
    url = "https://kaycebasques.github.io/doxybin/20241125/ubuntu-gcc-release.zip",
    sha256 = "f479c0eed0b0de28f58c6c7997c38d282b7afadf73dd132199019e4ff7f100f2",
    type = "zip",
    build_file_content = """
filegroup(
    name = "files",
    srcs = ["doxygen"],
    visibility = ["//visibility:public"],
)
sh_binary(
    name = "executable",
    srcs = ["doxygen"],
    data = [":files"],
    visibility = ["//visibility:public"],
)
""",
)

bazelisk run @doxygen_linux_gcc//:executable works as expected

also in MODULE.bazel I've patched it to use latest code like so:

git_override(
    module_name = "rules_doxygen",
    commit = "b8758dd1f8d54b6024e05c181b0a6f35d57e91e6",  # presumably I just use last commit from the WIP PR?
    remote = "https://github.com/tendto/rules_doxygen.git",
)
doxygen_extension = use_extension("@rules_doxygen//:extensions.bzl", "doxygen_extension")
doxygen_extension.configuration(
    platform = "linux",
    executable = "@doxygen_linux_gcc//:executable",
)

Trying to build the docs with the self-provided binary however leads to this error:

ERROR: Traceback (most recent call last):
	File "/home/kayce/.cache/bazel/_bazel_kayce/9659373b1552c281136de1c8eeb3080d/external/rules_doxygen+/extensions.bzl", line 258, column 44, in _doxygen_extension_impl
		executables.append(str(ctx.path(Label(attr.executable))) if attr.executable != "" else "")
Error in path: Unable to load package for @@[unknown repo 'doxygen_linux_gcc' requested from @@rules_doxygen+]//:executable: The repository '@@[unknown repo 'doxygen_linux_gcc' requested from @@rules_doxygen+]' could not be resolved: No repository visible as '@doxygen_linux_gcc' from repository '@@rules_doxygen+'
ERROR: error evaluating module extension doxygen_extension in @@rules_doxygen+//:extensions.bzl
INFO: Elapsed time: 0.112s
INFO: 0 processes.
ERROR: Build did NOT complete successfully
FAILED: 
    Fetching module extension doxygen_extension in @@rules_doxygen+//:extensions.bzl; starting

[TendTo]

Unfortunately I don't really understand all the details behind repository visibility at play here.
Based on my experimentation, try adding another @ before the label for the executable. It would become @@doxygen_linux_gcc//:executable.

[kaycebasques]

@TendTo we switched production pigweed.dev over to Bazel yesterday! Planning on writing a blog post and saying thanks to you for implementing these critical features and being very helpful/receptive in general. LMK if you'd prefer me to not mention you in the post

[kaycebasques]

blog post is here: https://pigweed.dev/docs/blog/08-bazel-docgen.html