[pmr_]

At first I thought "a build system which automatically figures out what to build and how to build it purely based on the source code" included figuring out library dependencies. It looks like I was wrong though and you still have to set linker and compiler flags yourself. I think actually understanding your dependencies (minimum versions, different build configurations and all) and handling them in a unified manner without too much special casing for the peculiarities. CMake already does this quite well, but there is still lots of room for improvement.

[kentonv]

It would be conceptually easy to extend Ekam to support automatically deciding which libraries to link against, and this has always been something I intended to do eventually, but it just hasn't happened yet.

In Ekam's link stage, it starts with a root object (typically, something exporting the symbol `main`) and then tries to satisfy all missing symbols using other built objects, transitively, until none of the remaining missing symbols are satisfied by any known objects. It then hopes those remaining symbols will be covered by libraries specified by the `LIBS` environment variable and so invokes the linker.

Ekam could additionally at this point consult an index of symbols exported by libraries in order to decide which ones to link against. We just need to implement such an index and decide how exactly a library gets included in the index.

I haven't implemented this because with Sandstorm we prefer instead to bring most of the source code for our dependencies into our build tree, so that they are in fact all built with Ekam instead of linking with pre-built system libs. This makes sense for Sandstorm since we intend to run in a chroot environment anyway and so cannot really share libraries with the rest of the system regardless. It's also really nice for development to be able to edit dependencies directly when needed and start using those changes in Sandstorm code without having to install the new library version somewhere as an interim step.

[hawski]

It's something that someday will come with clang modules support: http://clang.llvm.org/docs/Modules.html#includes-as-imports

With proper caching it could make local build systems obsolete for many purposes. Maybe it would be easier then to delegate module building in style similar to distcc, but less fragile.

[pmr_]

I'm not intending to put you, your enthusiasm, or the people behind Modules down: I've been hearing that story since C++11 was still called C++0x (this might be an exaggeration) but I don't see anything happening in terms of standardization. And as long as modules are not standardized they are not going to see widespread adoption in C++ and certainly not in the open source community.

Because I like to walk down the memory lane I've looked at my HN comments regarding modules. Here is one from exactly one year ago [1], 855 days ago [2], 1100 days ago.

[1]: https://news.ycombinator.com/item?id=7491149 [2]: https://news.ycombinator.com/item?id=4836499 [3]: https://news.ycombinator.com/item?id=3613636