Commit graph

21 commits

Author SHA1 Message Date
Ali Chraghi
49b7c940a9 {freetype, harfbuzz}: fix build error 2023-04-11 08:54:51 -07:00
Erik Arvstedt
858ba2eca5 freetype:harfbuzz: expose C API
Like in freetype.
2023-04-08 13:42:25 -07:00
Erik Arvstedt
b4685feb37 freetype:harfbuzz: fix type for shapers args
Non zero-terminated slices of the previous type caused runtime errors.
2023-04-08 13:41:31 -07:00
Erik Arvstedt
762a2074ee freetype: fix type for C string args
Propagate the correct string type required by Freetype to the Zig layer.
Previously, passing non zero-terminated strings caused runtime errors.
2023-04-08 13:41:31 -07:00
Keith Chambers
81fce62133
freetype: fix incorrect font path in embedFile (#636) 2022-12-14 02:19:34 -07:00
Ali Chraghi
a2c6319bc4 freetype: set packed structs backing integer 2022-11-01 08:59:13 -07:00
mlugg
ec8ced475f freetype: don't expose harfbuzz directly from freetype pkg
This declaration itself was nonsensical, as the file being imported was
from the harfbuzz package (instead users should import harfbuzz
directly). But as well as being nonsensical, this line was occasionally
triggering a stage2 bug which we haven't quite tracked down yet which
seems to be something to do with conflicting modules importing a file.
This issue meant that projects with a specific dependency pattern on
freetype and harfbuzz would sometimes randomly get a nonsensical
compilation error. This change works around that issue for
mach-freetype.
2022-09-30 12:25:19 -07:00
Ali Chraghi
77ee26d54e freetype: fix compilation errors 2022-09-30 12:24:14 -07:00
Ali Chraghi
82e10f4f28
all: build: thisDir improvements (#570)
* build:all: thisDir improvements

more performant output, usage code reducement and compileError for wrong usage

* glfw: update deprecated code
2022-09-29 08:41:46 -07:00
mlugg
2af8d5025b freetype/harfbuzz: correct Position struct layout
There's an undocumented private field in this struct which wasn't
replicated, meaning getGlyphPositions was returning garbage data.
2022-09-25 10:03:09 -07:00
Stephen Gutekanst
8113ca370d all: remove support for stage1
With almost all tests/examples working on all platforms now with the new compiler,
https://github.com/hexops/mach/issues/180, it's time to remove stage1 support.

Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2022-09-10 00:09:30 -07:00
Ali Chraghi
ad981944d4 all: revert cimport workaround 2022-09-07 21:24:47 -07:00
mlugg
0a32de381e freetype: correct return type of Face.availableSizes 2022-09-06 20:55:10 -07:00
NewbLuck
b7ea4aeb89
freetype: correct typo in previous fix (#509)
Co-authored-by: Scott Johnson <scott.johnson@furniturerow.com>
2022-09-02 09:44:46 -07:00
NewbLuck
2451d9e92b
freetype: Update padding size of packed structs (#507)
Co-authored-by: Ali Chraghi <63465728+alichraghi@users.noreply.github.com>
2022-09-01 23:57:41 -07:00
Ali Chraghi
1572ed7fc6 freetype: undepend to utils package 2022-08-29 05:59:52 -07:00
Ali Chraghi
16d4e374a9 freetype: drop c package 2022-08-28 10:45:09 -07:00
Stephen Gutekanst
1e0fa20622 all: employ self-hosted @cImport hack only on Darwin targets
This is an poor approximation for the host OS running Darwin, which
is good enough for now. In practice this means macOS works but can't
cross-compile (until the cImport issue is fixed in Zig itself), but
Windows/Linux are unaffected and should be able to build natively and
cross-compile.

Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2022-08-27 11:19:57 -07:00
Ali Chraghi
cb760cbbf6 freetype: complete *Scanline Converter* binding 2022-08-27 11:12:07 -07:00
Stephen Gutekanst
8019d55fe5 freetype: improve self-hosted compiler support (use darwin @cImport workaround)
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2022-08-26 19:03:55 -07:00
Stephen Gutekanst
0645429df9 all: move standalone libraries to libs/ subdirectory
The root dir of our repository has grown quite a lot the past few months.

I'd like to make it more clear where the bulk of the engine lives (`src/`) and
also make it more clear which Mach libraries are consumable as standalone projects.

As for the name of this directory, `libs` was my first choice but there's a bit of
a convention of that being external libraries in Zig projects _today_, while these
are libraries maintained as part of Mach in this repository - not external ones.

We will name this directory `libs`, and if we have a need for external libraries
we will use `external` or `deps` for that directory name. I considered other names
such as `components`, `systems`, `modules` (which are bad as they overlap with
major ECS / engine concepts), and it seems likely the official Zig package manager
will break the convention of using a `libs` dir anyway.

Performed via:

```sh
mkdir libs/
git mv freetype libs/
git mv basisu libs/
git mv gamemode libs/
git mv glfw libs/
git mv gpu libs/
git mv gpu-dawn libs/
git mv sysaudio libs/
git mv sysjs libs/
git mv ecs libs/
```

git-subtree-dir: glfw
git-subtree-mainline: 0d5b853443
git-subtree-split: 572d1144f11b353abdb64fff828b25a4f0fbb7ca

Signed-off-by: Stephen Gutekanst <stephen@hexops.com>

git mv ecs libs/

Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2022-08-26 15:12:04 -07:00