Hacker News Reader

Comment by mgaunard | Hacker News Reader

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?

View on HN

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)

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.

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

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

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?

because that usually leads to unnecessary builds and ODR violations.

Reply on news.ycombinator.com