Hacker News Reader

Comment by moyix | Hacker News Reader

Nice idea! The more data the better, from my perspective :) Presumably a lot of the code overlaps, but there's also probably plenty that's only in FreeBSD.

I would love to extend this even further to include projects on GitHub, but once you step outside the distro build systems it gets impossible to actually compile them in any standardized way. I might try to do some kind of best-effort (try ./configure && make, cmake, etc.) though.

View on HN

Or you could try a package repository for one of the C/C++ package managers. For example, for build2[1] we currently have ~300 packages[2] which you can all build in a uniform way.

[1] https://build2.org

[2] https://cppget.org

Neat, I will give those a shot!

> […] but once you step outside the distro build systems it gets impossible to actually compile them in any standardized way.

FreeBSD Ports allows you to specify GH information to pull down code/tarballs in a standardized fashion:

* https://wiki.freebsd.org/Ports/SimpleGithub

* https://docs.freebsd.org/en/books/porters-handbook/makefiles...

Then you'd list build- and run-time dependencies.

Right, and I definitely want to try building existing ports. But unless I'm missing something, this still requires you to write down by hand the dependencies and steps for actually building each project? That's not really feasible at the scale of GitHub.

True: there is no embedded metadata (à la Dublin Core) in the source code or in/on Github that tells you about how to compile the source code. There is still a human-involved step in looking at the source code, even if it is in a build infrastructure (like Ports or Homebrew) it still had to be put there by a human.

The closest thing for a source hub and automated build system that is probably CPAN and the like (PIP, CRAN).

Another build infrastructure, focused more in the HPC niche, is Spack:

* https://spack.io

* https://spack-tutorial.readthedocs.io/en/latest/index.html

Reply on news.ycombinator.com