Please follow RFC16 use SPDX identifier.
https://gitlab.archlinux.org/archlinux/rfcs/-/blob/master/rfcs/0016-spdx-license-identifiers.rst
Search Criteria
Package Details: cmake-format 0.6.13-3
Package Actions
| Git Clone URL: | https://aur.archlinux.org/cmake-format.git (read-only, click to copy) |
|---|---|
| Package Base: | cmake-format |
| Description: | Source code formatter for CMake listfiles |
| Upstream URL: | https://github.com/cheshirekow/cmake_format |
| Licenses: | GPL3 |
| Conflicts: | python-cmakelang |
| Provides: | python-cmakelang |
| Submitter: | Martchus |
| Maintainer: | Martchus (sum01, Martchus) |
| Last Packager: | Martchus |
| Votes: | 14 |
| Popularity: | 0.30 |
| First Submitted: | 2018-12-05 15:56 (UTC) |
| Last Updated: | 2023-06-26 09:27 (UTC) |
Dependencies (6)
- python-six
- python-setuptools (make)
- cmake (cmake-gitAUR) (check)
- python-argcomplete (python-argcomplete-gitAUR) (optional) – automatic shell completion
- python-jinja (optional) – complete HTML annotation
- python-yaml (python-yaml-gitAUR) (optional) – YAML config files
Required by (3)
Sources (1)
Coelacanthus commented on 2024-01-16 16:40 (UTC)
tpkessler commented on 2022-12-08 14:52 (UTC) (edited on 2022-12-08 14:56 (UTC) by tpkessler)
Hey! TU here. I agree with @Martchus that it's better to drop the python prefix. python-cmakelang has been merged into cmake-format.
Martchus commented on 2022-11-07 21:04 (UTC)
I think it is called cmake-format because that's what the whole project started with (and still the most important/popular outcome of the project). I guess it was only generalized later.
I've already filed a merge request to merge the other package into this but it hasn't been handled yet by a TU.
Spixmaster commented on 2022-11-07 17:10 (UTC)
The project name is confusing. I think it is cmake lang but the repository is named differently.
Spixmaster commented on 2022-11-07 17:09 (UTC)
Martchus commented on 2022-10-31 09:28 (UTC) (edited on 2022-10-31 09:29 (UTC) by Martchus)
The other package also seems broken as I suppose the setup tools should not just be a make dependency. It also doesn't execute the upstream testsuite.
I could add an additional provide here to mitigate any dependency issues.
Martchus commented on 2022-10-31 09:23 (UTC)
Since this package contains user facing tools and the used programming language is merely an implementation detail I'd avoid using the python- prefix in the name. Maybe internal Python modules could be split packages, though. So I would prefer to not delete this package.
Martchus commented on 2020-04-30 17:35 (UTC)
I was able to build the latest version. Do you build in a clean chroot? Otherwise the build system might pick up some tool for Debian packaging in your environment which doesn't work. That's just a guess. Without your full build log I can't say anything more specific.
vinci commented on 2020-04-30 11:15 (UTC)
The latest version gives me a CMake Error: CMake Error at cmake/debian.cmake:43 (add_dependencies): The dependency target "debs-Lysia-amd64" of target "debs" does not exist. Call Stack (most recent call first): CMakeLists.txt:29 (include)
Martchus commented on 2020-01-25 10:07 (UTC)
Read my previous comment.
Pinned Comments
Martchus commented on 2018-12-24 14:11 (UTC)
All my packages are managed at GitHub where you can also contribute directly: https://github.com/Martchus/PKGBUILDs There also exist a binary repository: https://martchus.no-ip.biz/repo/arch/ownstuff