Commit Graph

3 Commits

Author SHA1 Message Date
Justin C. Miller
5d1fdd0e81 [all] Reference headers in src instead of copying
This is the second of two big changes to clean up includes throughout
the project. Since I've started using clangd with Neovim and using
VSCode's intellisense, my former strategy of copying all header files
into place in `build/include` means that the real files don't show up in
`compile_commands.json` and so display many include errors when viewing
those header files in those tools.

That setup was mostly predicated on a desire to keep directory depths
small, but really I don't think paths like `src/libraries/j6/j6` are
much better than `src/libraries/j6/include/j6`, and the latter doesn't
have the aforementioned issues, and is clearer to the casual observer as
well.

Some additional changes:

- Added a new module flag `copy_headers` for behavior similar to the old
  style, but placing headers in `$module_dir/include` instead of the
  global `build/include`. This was needed for external projects that
  don't follow the same source/headers folder structure - in this case,
  `zstd`.
- There is no longer an associated `headers.*.ninja` for each
  `module.*.ninja` file, as only parsed headers need to be listed; this
  functionality has been moved back into the module's ninja file.
2023-07-12 19:45:43 -07:00
Justin C. Miller
4545256b49 [build] Move headers out of target dirs
The great header shift: It didn't make sense to regenerate headers for
the same module for every target (boot/kernel/user) it appeared in. And
now that core headers are out of src/include, this was going to cause
problems for the new libc changes I've been working on. So I went back
to re-design how module headers work.

Pre-requisites:
- A module's public headers should all be available in one location, not
  tied to target.
- No accidental includes. Another module should not be able to include
  anything (creating an implicit dependency) from a module without
  declaring an explicit dependency.
- Exception to the previous: libc's headers should be available to all,
  at least for the freestanding headers.

New system:
- A new "public_headers" property of module declares all public headers
  that should be available to dependant modules
- All public headers (after possible processing) are installed relative
  to build/include/<module> with the same path as their source
- This also means no "include" dir in modules is necessary. If a header
  should be included as <j6/types.h> then its source should be
  src/libraries/j6/j6/types.h - this caused the most churn as all public
  header sources moved one directory up.
- The "includes" property of a module is local only to that module now,
  it does not create any implicit public interface

Other changes:
- The bonnibel concept of sources changed: instead of sources having
  actions, they themselves are an instance of a (sub)class of Source,
  which provides all the necessary information itself.
- Along with the above, rule names were standardized into <type>.<ext>,
  eg "compile.cpp" or "parse.cog"
- cog and cogflags variables moved from per-target scope to global scope
  in the build files.
- libc gained a more dynamic .module file
2022-02-06 10:18:51 -08:00
95a35cd0bf [libc] Bring libc in-tree
Moving libc from its separate repo into this one, minor resulting build
fixes, and a hacky way to add -I for libc headers in builds.
2020-08-23 17:21:08 -07:00