helloiamsomeone

2년 전discuss

What exactly is tricky about MMOs? World of Warcraft private servers are a thing and there are many more MMOs with private servers.

The tricky part for private servers right now is someone having to apply elbow grease, reverse engineer things, while the publisher has the legal power to shut it down and punish people for trying to bring back a dead game they don't even support anymore.

helloiamsomeone

2년 전discuss

>Vote with your money.

This does not work with video games, unless you were a whale to begin with. Whales spend magnitudes more money on games than the average players [1]. Companies know this and exploit this weakness in the human psychology.

Just because you decided to not buy a game for $60, that will not stop a whale from dropping thousands and more.

[1]: https://sg.news.yahoo.com/whales-games-genshin-impact-compet...

helloiamsomeone

2년 전discuss

Software is in fact eternal. Maxwell’s Equations of Software (Lisp) is still a thing to this day [1]. Even for software designed for arcane architectures. You can simulate the Apollo Guidance Computer and its software today [2], which got people on the Moon. Technological progress must never come at the expense of people's rights.

[1]: https://github.com/jart/sectorlisp [2]: https://www.ibiblio.org/apollo/

helloiamsomeone

2년 전discuss

If you are hardcoding anything platform related into your CML, you are doing that wrong. The default path must not be anything other than build and usage requirements. To support more usecases with CMake, you have to write less of it.

helloiamsomeone

2년 전discuss

> As far as I can see, the best choice for writing bootstrap-related software in 2024 is still C99

That seems a bit silly, since going from ISO C99 to C++ is only one more build away[0] and from there you can practically build the whole world as you please.

> CMake is absolutely out

Considering how hostile Meson is to platforms other than *nix[1], I doubt there is any realistic alternative here.

> I still haven’t forgiven it for deciding that the space-separated output of pkg-config meant it was a “list”, then emitting that list as a semicolon-separated string into my build commands.

I'd be curious where the issue opened by the author is, since this would be a pretty big problem if it was truly an issue. The CMake module processing the output of pkg-config is also just using an existing CMake command[2], so the impact would be greater than just pkg-config related code if there really was an issue.

[0]: https://blog.dave.tf/post/finding-bottom-turtle/

[1]: https://github.com/mesonbuild/meson/issues/8153

[2]: https://gitlab.kitware.com/cmake/cmake/-/blob/f8ba5b12ca842c...

helloiamsomeone

2년 전discuss

The software distribution side of CMake is there and it serves many needs, so you can't really get a clear answer here, because only you know what you really need.

Package discovery for example can be done with the CMAKE_PREFIX_PATH[1] command line cache variable, which is a list of prefixes where find_*() commands will go looking for things. But if you are putting your own install prefix together, or are using a system prefix, then CMAKE_INSTALL_PREFIX[2] can also serve that purpose and it will also set the default install prefix for cmake --install. You can also control discovery on a per find_*() command basis using various environment and cache variables, all documented in their respective documentation. For example, see the numbered list in find_package's documentation[3].

Setting RPATH can be done at a project level using the CMAKE_INSTALL_RPATH[4] variable. However, if you have both executables and libraries in a project, you might see how that may not be the most useful approach and instead you'd want to reach for CPack scripting (via CPACK_PRE_BUILD_SCRIPTS[5]) to setup RPATH separately for things going in /bin and /lib.

Software distribution is messy and CMake provides tools to deal with things, but you have to know what's the most appropriate soltuion for your case.

[1]: https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PA...

[2]: https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_P...

[3]: https://cmake.org/cmake/help/latest/command/find_package.htm...

[4]: https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_R...

[5]: https://cmake.org/cmake/help/latest/module/CPack.html#variab...

helloiamsomeone

2년 전discuss

> give me a `set -u` equivalent

--warn-uninitialized and -Werror=dev will do just that: https://cmake.org/cmake/help/latest/manual/cmake.1.html

helloiamsomeone

2년 전discuss

> find_package often just ends up using pkg-config

find_package() is just a souped-up include(). What happens once it finds the script matching the criteria provided by arguments and cache variables depends entirely on the script(s) (plural, because version criterion is satisfied by the *ConfigVersion.cmake script for config mode search) it runs. The PkgConfig module is only mentioned in a couple of CMake provided find modules:

    >find -maxdepth 1 -type f -name "Find*.cmake" -not -name FindPkgConfig.cmake -exec ugrep -HFe PkgConfig {} + | cut -d: -f1 | sort | uniq | sed s/..//;s/\.cmake//
    FindBLAS
    FindCURL
    FindCurses
    FindEXPAT
    FindFontconfig
    FindGLUT
    FindGSL
    FindGnuTLS
    FindImageMagick
    FindLAPACK
    FindLibXml2
    FindLibXslt
    FindLibinput
    FindMPI
    FindOpenSP
    FindOpenSSL

The prevalent method of discovering packages is via the package provided config scripts, which of course have to come from upstream. Kitware stopped adding new find modules, because they are not worth the maintenance effort (e.g. find modules require maintaining a list of versions like for Python or Boost) and instead upstreams should provide a proper CMake package.

pkg-config also really only works in the Linux bubble. CPS[1] is trying to bridge the gap here if you are interested.

[1]: https://github.com/cps-org/cps

comments