#Abuse of the build system

1 messages · Page 1 of 1 (latest)

grim moat
#

I'm porting a reasonably sized C++ application to the zig build system. The source tree is laid out like this:

├── src
│   ├── Common
│   │   └── include
│   ├── Core
│   │   ├── include
│   │   └── ...
│   ├── Plugins.Win32.Etc
│   │   └── ...
│   ├── Views.Win32
│   │   ├── include
│   │   └── ...
├── vendor
┆   ┆── ...

Core depends on Common, Views.Win32 depends on Common, and the plugins depend on Views.Win32, and all the vendored libs which are whatever

I thought it would be a good idea to have a separate build.zig for each submodule. Instead of using addLibrary or addExecutable, I use addModule to deal with the source files and addNamedLazyPath to add the include path, and consolidate everything at the root.

exe.root_module.addIncludePath(common_dep.namedLazyPath("include"));
exe.root_module.addIncludePath(core_dep.namedLazyPath("include"));
exe.root_module.addIncludePath(views_win32_dep.namedLazyPath("include"));

exe.root_module.addImport("", core_dep.module("Core"));
exe.root_module.addImport("", views_win32_dep.module("Views.Win32"));

It works, but is this a stupid idea??? Is there something less stupid I should be doing instead of this???

#

i'm probably overcomplicating this a little bit

#

ok yeah i'm definitely overcomplicating this

#

i only need the headers and i wanted to use linkLibrary to automatically include them but now i'm completely circumventing that

#

and some of the submodules/vendored dependencies (like Common) are header-only which is irritating

vague kestrel
#

Most things that are "header-only" really aren't truly header-only. These are better described as "single file" libraries. They're a header and an implementation in the same file, switched between declaration and implementation via macros. If you know it's one of those, then you know that you need to have the implementation part happening in some translation unit somewhere.

grim moat