Specify a custom std c lib to use in dependency

Help
,
1

Context

zig version: 0.15.1

I’m trying to port littlefs as zig module. I plane to use this module on laptop program but also for embedded targets (zig target: thumb-freestanding-eabi). For embedded target, I use microzig framework and their lib c called foundatation.

Infortunatly, littlefs c header include c stdlib in it (#include <string.h> at least).
So I need to link littlefs with a c stdlib, fine.

My build.zig

I write this to my project build.zig:

      const foundation_dep = b.dependency("foundationlibc", .{
          .target = resolved_zig_target,
          .optimize = optimize,
      });

      const lfs_translate = b.addTranslateC(.{
          .root_source_file = littlefs_dep.path("lfs.h"),
          .target = resolved_zig_target,
          .optimize = optimize,
          .link_libc = false,
      });
      lfs_translate.defineCMacro("LFS_NO_DEBUG", "1");
      lfs_translate.defineCMacro("LFS_NO_WARN", "1");
      lfs_translate.defineCMacro("LFS_NO_ERROR", "1");
      lfs_translate.defineCMacro("LFS_NO_MALLOC", "1");
      // add this to let TranslateC know where is "string.h"
      lfs_translate.addIncludePath(foundation_dep.path("include"));

      // create the module
      const lfs_mod = lfs_translate.addModule("lfs");
      lfs_mod.linkLibrary(foundation_dep.artifact("foundation"));
      lfs_mod.addIncludePath(littlefs_dep.path(""));
      lfs_mod.addCMacro("LFS_NO_DEBUG", "1");
      lfs_mod.addCMacro("LFS_NO_WARN", "1");
      lfs_mod.addCMacro("LFS_NO_ERROR", "1");
      lfs_mod.addCMacro("LFS_NO_MALLOC", "1");
      lfs_mod.addCSourceFiles(.{
          .root = littlefs_dep.path(""),
          .files = &.{ "lfs.c", "lfs_util.c" },
          .flags = &.{},
      });

      fw.app_mod.addImport("littlefs", lfs_mod);

Question

I want to package it and be able to get it from build.zig.zon but I don’t understand how I can let user specify the libc for the TranslateC step ?
Or maybe I’m wrong and this type of lib shouldn’t be put in dedicated package ?

Thanks,

2

To clarify, you want users of your package to be able to override what libc is used?

Put the linking of foundation behind a build flag, the users of your package can then disable it and link their own., didnt see its for translate c

provide public functions in your build.zig to deal with the boilerplate, dependees can @import("dep_name") to import the build.zig of dependencies, and access public declarations.

edit: my brain isnt working rn, i think you can just use build options,

3

Don’t know if there’s a better way, but you can always fall back to calling a function in a Zig package’s build.zig.

For instance sokol-zig still supports the ‘pre-package-manager’ way of calling a buildLibSokol function from an upstream build.zig. This function returns a !*Build.Step.Compile (same as std.Build.addLibrary() plus error condition).

In the top-level build.zig calling a function in a dependency package is straightforward. For instance if you have a build.zig.zon dependency called sokol you can simply import that in your toplevel build.zig:

const sokol = @import("sokol");

…and then call public functions on it:

const sokol_clib_step = sokol.buildLibSokol(...);

…and the returned CompileStep can be used to setup dependencies (the library had already been added to the Build object via b.addLibrary() inside the buildLibSokol function.

…I guess one thing to be aware of is to make sure that other dependencies don’t accidentially link with the regular C stdlib (e.g. I guess mixing two stdlibs in the same projects isn’t a good idea).

4

PS: another thing:

Maybe for the translateC step you don’t actually want to use the target platform’s target-triple though but instead use the host platform’s build triple?

For instance in the dcimgui build.zig - where I’m also doing a translateC - I’m specifically hardwiring that step to the host platform to avoid having to setup header search paths for external SDKs (like Emscripten):

…e.g. note the .target = b.graph.host.

1 Like
5

Ah right I went down the same deadend lol :smiley:

To clarify: you can pass random build options when looking up a dependency. For instance in the sokol-zig build.zig I define a whole lot of build options to customize the sokol-library build:

…from an upstream project you can pass those options in the b.dependency call, like I’m doing here with the .with_sokol_imgui flag:

…those build options are not typed, and the whole feature to pass down build options into dependencies isn’t all that obvious…

PS: I think for this specific use case (translateC step) it’s probably better to hardwire the target platform of the translateC step to the host platform though like I described above for dcimgui.

6

Thanks for all your reply. So I follow your advice and add an option to pass a custom inc dir when stdlib is disable.