[libc-commits] [PATCH] D81533: [libc] Add a simple linux aarch64 config.

[Siva Chandra via Phabricator via libc-commits]

sivachandra added a comment.

In D81533#2084124 <https://reviews.llvm.org/D81533#2084124>, @abrachet wrote:

> I don't know the solution here, but there is so much which we end up copying between configs of architectures. It's most apparent with the math.h targets because our implementations are architecture and OS agnostic, but most of libc except for `syscall` like you mention is too. I think it's clear that having separate build config files for every OS * architecture is untenably difficult for us to maintain. I should have mentioned this earlier, it's not this patch which introduced this, but I didn't catch it then.
>
> What if we had something like
>
> name=config/entrypoints.txt
>   set(TARGET_LIBC_ENTRYPOINTS
>    ...
>   )
>  
>   add_subdirectory(${OS})
>   append(TARGET_LIBC_ENTRYPOINTS ${OS}_LIBC_ENTRYPOINTS) # or whatever the command for concatenating lists is
>   add_subdirectory(${ARCH})
>   append(...)
>
>
> Or maybe the other way around where arch specific file has a set of targets it explicitly doesn't have support yet.
>
> There might even be a clever way to do it with CMake and dependencies, like you said most which didn't make the list here for `TARGET_LIBC_ENTRYPOINTS` so we could have base targets like `syscall` and if those are missing from a target then we skip its tests.
>
> Whatever the solution is, I don't think copying for every arch is the right way to go and even if it works right now, and I would be willing to move forward to make progress, we need an eventual solution.


I completely agree. I do not have a good solution either. If copying is the only problem, I wouldn't have worried that much here. But, there are problems beyond just copying. For example, the roles of `api.td` and `headers.txt` is mixed up. As you suggest, running tests only if all deps are available is an approach but there are short comings there as well. While we try to evolve our system, we need to have a way to move forward so I have stuck to the current approach for now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81533/new/

https://reviews.llvm.org/D81533