[all-commits] [llvm/llvm-project] 722c06: [libc] Make use of 32-bit time_t a config option (...

[Simon Tatham via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 722c066c59b25bc73f41dbe92193319aa5b8783a
      https://github.com/llvm/llvm-project/commit/722c066c59b25bc73f41dbe92193319aa5b8783a
  Author: Simon Tatham <simon.tatham at arm.com>
  Date:   2024-08-08 (Thu, 08 Aug 2024)

  Changed paths:
    M libc/cmake/modules/LLVMLibCCompileOptionRules.cmake
    M libc/cmake/modules/LLVMLibCFlagRules.cmake
    M libc/cmake/modules/LLVMLibCHeaderRules.cmake
    M libc/config/config.json
    M libc/docs/configure.rst
    M libc/include/llvm-libc-types/CMakeLists.txt
    M libc/include/llvm-libc-types/time_t.h
    A libc/include/llvm-libc-types/time_t_32.h
    A libc/include/llvm-libc-types/time_t_64.h

  Log Message:
  -----------
  [libc] Make use of 32-bit time_t a config option (#102012)

The 32-bit Arm builds of libc define time_t to be `__INTPTR_TYPE__`,
i.e. a 32-bit integer. This is commented in the commit introducing it
(75398f28ebdb600) as being for compatibility with glibc. But in the near
future not even every AArch32 build of glibc will have a 32-bit time_t:
Debian is planning that their next release (trixie) will have switched
to 64-bit. And non-Linux builds of this libc (e.g. baremetal) have no
reason to need glibc compatibility in the first place – and every reason
_not_ to want to start using a 32-bit time_t in 2024 or later.

So I've replaced the `#ifdef` in `llvm-libc-types/time_t.h` with two
versions of the header file, chosen in `CMakeLists.txt` via a new
configuration option. This involved adding an extra parameter to the
cmake `add_header` function to specify different names for the header
file in the source and destination directories.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications