[mgaunard]

many build systems have a notion of build targets, with various target types (static/shared library, module, executable, etc.).

You don't have that (which I personally find is good, but that's arguably because I'm opinionated about not having libraries), but how do you deduce what to link and what are the entrypoints?

[AI314159]

Currently, I just have "binary" targets, which output an executable, and "library" targets which output a static library. This is decided by a flag in the TOML [package] table: is_lib = true|false. For a binary project, it just links as normal, using the compiler as the linker by default (also can be changed through TOML). Thus, the entry point is `main()`. However, for libraries, the object files are configured the same, and it calls my link function, but with different arguments and `ar` set as the linker. Therefore, a `.a` file is created. (Probably this is my biggest source of Windows incompatibilities)

[mgaunard]

so a project is a single target, and you still have the notion of libraries (which to me are an anti-pattern).

so no interest from me personally.

[AI314159]

That's alright! However, if you don't mind me asking, what would make you potentially interested?

[mgaunard]

track dependencies at the source level, only build what you need, guarantee single version of a source throughout the program

[arjonagelhout]

Could you elaborate on why you think libraries are an anti-pattern?

Is the alternative just one library or executable, with namespaces and directory structure being the source of truth for organization of a codebase?

[mgaunard]

because that usually leads to unnecessary builds and ODR violations.