6 ms·

Couldn't they still do this? I think there was a project a ways back to add a lua frontend to CMake. It's been since abandoned, but I don't see why it couldn't

Couldn't they still do this? I think there was a project a ways back to add a lua frontend to CMake. It's been since abandoned, but I don't see why it couldn't be revitalized. I guess the project just doesn't see the value in doing it, or they don't have enough manpower.

mathstuf 5y ago
See my sibling comment. The way CMake's language has evolved is very organic. There is a declarative core now with targets and usage requirements, but due to backwards compatibility guarantees, actually making it the only thing available is nigh impossible. Lua was also deemed not suitable in the long run because of our backwards compatibility guarantees. We'd need to ship N Lua interpreters internally because Lua is not compatible between 5.1, 5.2, 5.3, etc. Or say "we only support Lua 5.2, we cannot support 5.4" which…distros really dislike.
- enriquto 5y ago
  10 lua interpreters would still be less than 1% of the cmake code base. Shipping all of them would be orders of magnitude better than the current clusterfuck that cmake is. But in reality you would only need one.
  - mathstuf 5y ago
    Except that our testing and behavior matrix now explodes. It's not the code I'd be worried about maintaining: it's the effects and interactions of that code.
    - enriquto 5y ago
      It has already much exploded, fractally several times around. My main portability problem when building packages is the very existence different cmake versions, and hardcoded cmake version requirements in cmakelists.
      - mathstuf 5y ago
        > My main portability problem when building packages is the very existence different cmake versions Why? You should always be able to update CMake and have it continue to work. If not, that's a regression in CMake and we take those very seriously.
        krapht 5y ago
        I think parent is referring to the fact that for many Linux distributions, you must build packages with the version of CMake they have in the repositories. Even today, in 2021, I have to use CMake 2.8.12 / GCC 4.8.5 in order to build code that will deploy on a CentOS 7 server. That means I have to backport the CMake file of every dependency that declares a minimum_requirement of 3+.
        mathstuf 5y ago
        If you want to be in that distro repo, yeah. If you're just building on CentOS 7, download newer binaries (https://github.com/Kitware/CMake/releases https://github.com/Kitware/CMake/releases) and use them instead. I do this all the time for our CentOS 7 deployments (and we use gcc 8 or 9; I forget when we last uplifted the devtoolset). FWIW, `cmake3` is packaged in CentOS 7 (though it might be EPEL?). All that said, given CMake's backwards compatibility guarantees, it is a bit silly that distributions don't update CMake more aggressively.
        enriquto 5y ago
        > it is a bit silly that distributions don't update CMake more aggressively. this would actually worsen the problem. Main issue is the message "Compatibility with CMake < 2.8.12 will be removed from a future version of CMake" that appears so often when compiling older codes (not that old, written three or four years ago). When you change the version requirement on the offending CMakeLists.txt, the compilation breaks subtly and then you have to spend a very romantic afternoon with the build system and its beautiful language. Backwards compatibility. You keep using that word. I do not think it means what you think it means.
- abz10 5y ago
  I may not be understanding something; wouldn’t the Lua be embedded? So yeah, you’d pick a version. Why wouldn’t distros like it?
  - mathstuf 5y ago
    Multiple issues: - Distros like unbundling (vcpkg, Anaconda, Spack, etc. also do too) - Old releases of Lua are not maintained, so it would be our problem - Compiled Lua packages need to match our build (and since we'd likely need multiple Lua versions, our symbols would be mangled, so nothing would work unless explicitly compiled against CMake's version). I really don't want to deal with "why can't I use Lua package XYZ?" issues every week
- Zababa 5y ago
  I know this might seem weird, but did you consider JavaScript? It takes backwards compatibility very seriously and with QuickJS (https://bellard.org/quickjs/ https://bellard.org/quickjs/) you could embed it easily if you wish to do so. I do understand that it could be a big culture shock to ask people using CMake to suddenly learn JavaScript and use it, and it has its fair share of warts.
  - mathstuf 5y ago
    We hadn't at the time because the only JS engines we could think of were 10x larger than CMake because they were built for browsers and had all kinds of cruft for a DOM that CMake doesn't care about hanging around. Maybe QuickJS would work, but (personally) I don't really think the language would be all that much of an improvement over what we have today (my issues are mostly around the oddities of which JS has quite a number of due to its roots). Then again, some of the ideas that have been tossed around for what could happen are probably interfering and I don't think JS would make those things any easier.
    - Zababa 5y ago
      That makes a lot of sense, I understand not wanting to deal with V8 or Spidermonkey and the JS-specific warts. Thanks.

mathstuf 5y ago

See my sibling comment. The way CMake's language has evolved is very organic. There is a declarative core now with targets and usage requirements, but due to backwards compatibility guarantees, actually making it the only thing available is nigh impossible. Lua was also deemed not suitable in the long run because of our backwards compatibility guarantees. We'd need to ship N Lua interpreters internally because Lua is not compatible between 5.1, 5.2, 5.3, etc. Or say "we only support Lua 5.2, we cannot support 5.4" which…distros really dislike.

enriquto 5y ago
10 lua interpreters would still be less than 1% of the cmake code base. Shipping all of them would be orders of magnitude better than the current clusterfuck that cmake is. But in reality you would only need one.
- mathstuf 5y ago
  Except that our testing and behavior matrix now explodes. It's not the code I'd be worried about maintaining: it's the effects and interactions of that code.
  - enriquto 5y ago
    It has already much exploded, fractally several times around. My main portability problem when building packages is the very existence different cmake versions, and hardcoded cmake version requirements in cmakelists.
    - mathstuf 5y ago
      > My main portability problem when building packages is the very existence different cmake versions Why? You should always be able to update CMake and have it continue to work. If not, that's a regression in CMake and we take those very seriously.
      - krapht 5y ago
        I think parent is referring to the fact that for many Linux distributions, you must build packages with the version of CMake they have in the repositories. Even today, in 2021, I have to use CMake 2.8.12 / GCC 4.8.5 in order to build code that will deploy on a CentOS 7 server. That means I have to backport the CMake file of every dependency that declares a minimum_requirement of 3+.
        mathstuf 5y ago
        If you want to be in that distro repo, yeah. If you're just building on CentOS 7, download newer binaries (https://github.com/Kitware/CMake/releases https://github.com/Kitware/CMake/releases) and use them instead. I do this all the time for our CentOS 7 deployments (and we use gcc 8 or 9; I forget when we last uplifted the devtoolset). FWIW, `cmake3` is packaged in CentOS 7 (though it might be EPEL?). All that said, given CMake's backwards compatibility guarantees, it is a bit silly that distributions don't update CMake more aggressively.
        enriquto 5y ago
        > it is a bit silly that distributions don't update CMake more aggressively. this would actually worsen the problem. Main issue is the message "Compatibility with CMake < 2.8.12 will be removed from a future version of CMake" that appears so often when compiling older codes (not that old, written three or four years ago). When you change the version requirement on the offending CMakeLists.txt, the compilation breaks subtly and then you have to spend a very romantic afternoon with the build system and its beautiful language. Backwards compatibility. You keep using that word. I do not think it means what you think it means.
abz10 5y ago
I may not be understanding something; wouldn’t the Lua be embedded? So yeah, you’d pick a version. Why wouldn’t distros like it?
- mathstuf 5y ago
  Multiple issues: - Distros like unbundling (vcpkg, Anaconda, Spack, etc. also do too) - Old releases of Lua are not maintained, so it would be our problem - Compiled Lua packages need to match our build (and since we'd likely need multiple Lua versions, our symbols would be mangled, so nothing would work unless explicitly compiled against CMake's version). I really don't want to deal with "why can't I use Lua package XYZ?" issues every week
Zababa 5y ago
I know this might seem weird, but did you consider JavaScript? It takes backwards compatibility very seriously and with QuickJS (https://bellard.org/quickjs/ https://bellard.org/quickjs/) you could embed it easily if you wish to do so. I do understand that it could be a big culture shock to ask people using CMake to suddenly learn JavaScript and use it, and it has its fair share of warts.
- mathstuf 5y ago
  We hadn't at the time because the only JS engines we could think of were 10x larger than CMake because they were built for browsers and had all kinds of cruft for a DOM that CMake doesn't care about hanging around. Maybe QuickJS would work, but (personally) I don't really think the language would be all that much of an improvement over what we have today (my issues are mostly around the oddities of which JS has quite a number of due to its roots). Then again, some of the ideas that have been tossed around for what could happen are probably interfering and I don't think JS would make those things any easier.
  - Zababa 5y ago
    That makes a lot of sense, I understand not wanting to deal with V8 or Spidermonkey and the JS-specific warts. Thanks.