Commit Graph

6 Commits

Author SHA1 Message Date
Dan Zheng c03b5da542 Copybara configuration update.
PiperOrigin-RevId: 609931218
2024-02-24 12:02:47 -08:00
Austin Huang 34b22c56f5
Merge pull request #6 from dcoles/clang-cl
Allow building on Windows using `clang-cl` toolchain
2024-02-24 12:27:40 -05:00
Ikko Eltociear Ashimine e4e02a17d4 Copybara import of the project:
--
5c7dbc6599 by Ikko Eltociear Ashimine <eltociear@gmail.com>:

Update build.yml

dispath -> dispatch

COPYBARA_INTEGRATE_REVIEW=https://github.com/google/gemma.cpp/pull/22 from eltociear:patch-1 5c7dbc6599
PiperOrigin-RevId: 609827161
2024-02-23 22:32:51 -08:00
David Coles 39e385782c Allow building on Windows using `clang-cl` toolchain
It's not possible to build `gemma.cpp` with the standard MSVC front-end
as it doesn't support arrays more than `0x7ffffffff` bytes (see Compiler Error C2148),
however this isn't a problem with the optional Visual Studio Clang/LLVM frontend.

This can be specified using the `-T` flag when running CMake:

```
$ cmake -B build -T ClangCL
$ cmake --build build --config Release
```

Windows doesn't provide `pread`/`pwrite` so this must be emulated using
the `ReadFile`/`WriteFile` Win32 APIs.

`_CRT_SECURE_NO_WARNINGS` is defined to prevent a large number of warnings
about using "depricated" function names (e.g. `close` instead of `_close`).

`NOMINMAX` is defined to prevent the `min`/`max` macros from `windows.h`
from conflicting with expressions like `std::min`. Generally libraries should
avoid including `windows.h` in their public headers or define `WIN32_LEAN_AND_MEAN`
before including the `windows.h` header, but this unfortunately isn't always the case.
2024-02-23 00:38:54 -08:00
The gemma_cpp Authors 587e80f276 Code update
PiperOrigin-RevId: 609394329
2024-02-22 09:19:47 -08:00
Austin Huang e29cd566cf initial commit 2024-02-21 03:31:22 +00:00