9 ms·

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 w

by moyix 5y ago

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.

boris 5y ago
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 https://build2.org [2] https://cppget.org https://cppget.org
- moyix 5y ago
  Neat, I will give those a shot!
throw0101a 5y ago
> […] 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://wiki.freebsd.org/Ports/SimpleGithub * https://docs.freebsd.org/en/books/porters-handbook/makefiles/ https://docs.freebsd.org/en/books/porters-handbook/makefiles... Then you'd list build- and run-time dependencies.
- moyix 5y ago
  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.
  - throw0101a 5y ago
    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.io * https://spack-tutorial.readthedocs.io/en/latest/index.html https://spack-tutorial.readthedocs.io/en/latest/index.html

by moyix 5y ago

boris 5y ago

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 https://build2.org [2] https://cppget.org https://cppget.org

moyix 5y ago
Neat, I will give those a shot!

throw0101a 5y ago

> […] 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://wiki.freebsd.org/Ports/SimpleGithub * https://docs.freebsd.org/en/books/porters-handbook/makefiles/ https://docs.freebsd.org/en/books/porters-handbook/makefiles... Then you'd list build- and run-time dependencies.

moyix 5y ago
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.
- throw0101a 5y ago
  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.io * https://spack-tutorial.readthedocs.io/en/latest/index.html https://spack-tutorial.readthedocs.io/en/latest/index.html