Search Criteria
Package Details: nchat-git 4.41.r6.gf0e91a37-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/nchat-git.git (read-only, click to copy) |
---|---|
Package Base: | nchat-git |
Description: | console-based chat client with support for Telegram |
Upstream URL: | https://github.com/d99kris/nchat |
Licenses: | MIT |
Conflicts: | nchat |
Provides: | nchat |
Submitter: | jonnieey |
Maintainer: | jonnieey (xiota) |
Last Packager: | xiota |
Votes: | 5 |
Popularity: | 0.38 |
First Submitted: | 2020-10-26 01:12 (UTC) |
Last Updated: | 2024-03-26 13:18 (UTC) |
Dependencies (10)
- file (file-gitAUR)
- ncurses (ncurses-gitAUR)
- openssl (openssl-gitAUR, openssl-staticAUR)
- sqlite (sqlite-fossilAUR)
- zlib (zlib-ng-compat-gitAUR, zlib-gitAUR, zlib-ng-compatAUR)
- cmake (cmake-gitAUR) (make)
- git (git-gitAUR) (make)
- go (go-gitAUR, gcc-go-gitAUR, gcc-go-snapshotAUR, gcc-go) (make)
- gperf (gperf-gitAUR) (make)
- ninja (ninja-kitwareAUR, ninja-memAUR, ninja-fuchsia-gitAUR, ninja-gitAUR, ninja-jobserverAUR) (make)
Latest Comments
1 2 Next › Last »
xiota commented on 2024-04-10 22:40 (UTC)
@HaoZeke Please post the exact error message.
HaoZeke commented on 2024-04-10 19:18 (UTC)
I've been having trouble with VCS related build flags, kept getting set
-buildvcs=false
. Finally fixed it with:gesh commented on 2024-03-27 10:58 (UTC)
OK, fine.
xiota commented on 2024-03-27 01:13 (UTC) (edited on 2024-03-27 02:20 (UTC) by xiota)
makepkg
needs to control the flags to work as intended.-O3
is not the only problematic build flag. Some projects attempt to force flags that produce broken packages.This package is working as intended. There is no reason to make any change right now. If you don't want to use
ninja
, run the following before building:gesh commented on 2024-03-26 16:56 (UTC) (edited on 2024-03-26 16:58 (UTC) by gesh)
Points taken, my understanding of the "avoid upstream config" guidance was that it was restricted to only trouble around
-O3
-- i.e. that the guidance was specifically to setCFLAGS+=(-DCMAKE_BUILD_TYPE=None)
, then add whatever other flags are necessary to make the project build again. But your description ofmake.sh
breaking the build is enough to convince me that, regardless of my understanding of the general case, in this case avoiding upstream's build methods is warranted.(The "vanilla packages" principle I alluded to is my understanding of https://wiki.archlinux.org/title/Arch_Linux#Simplicity)
(in re
readline
, misreadpacman -Q
output and thought it wasn't pulled in bybase
)Only remaining sticking point is
ninja
-- I see it as hardcoding a build process variant that's not strictly necessary, cf the critique of thenchat
package hardcoding in accache
makedep. What are the benefits you see in it that warrant hardcoding it in?xiota commented on 2024-03-26 15:32 (UTC)
You are incorrect either about the meaning of the "vanilla upstream" principle or its applicability. The CMake package guidelines strongly recommend setting build type to None specifically to prevent upstream developers from changing build settings, which directly opposes the principle you describe.
Custom shell scripts, including
make.sh
, often deviate from guidelines, which is why this package needed to be updated recently. Fixing the behavior of custom scripts requires more effort with poorer results than usingcmake
directly.readline
is not used during runtime, so does not belong in depends. Even if it were, it's pulled in bybase
, so the package is not broken by its absence.ninja
does a few things better thanmake
by default. I am leaving it.gesh commented on 2024-03-26 14:05 (UTC)
What guidelines does it break? IIUC, the principle is that we should packge as close to vanilla upstream as reasonable -- modifying the build mechanism seems to be in violation of that principle to me.
Which also doesn't address the use of ninja and the absence of the readline dep?
xiota commented on 2024-03-26 13:23 (UTC) (edited on 2024-03-26 13:24 (UTC) by xiota)
@gesh I am not using your PKGBUILD because it breaks multiple package guidelines. Removed
prepare()
function because it is not needed. No changes needed fordepends
,makedepends
,build()
, andpackage()
.gesh commented on 2024-03-26 13:10 (UTC) (edited on 2024-03-26 13:11 (UTC) by gesh)
The following patch should address my concerns -- tested, it builds.
gesh commented on 2024-03-26 12:16 (UTC) (edited on 2024-03-26 12:22 (UTC) by gesh)
The
file
dep is unnecessary -- it's part ofbase
.prepare()
has been unnecessary for more than two years now, since f4f7da0be00ce948a9a8de75fb21fd515f796d90 explicitly shouted it outUnclear where the
ninja
dep is from -- is this a dependency, or a suggestion? Things build fine with-G 'Unix Makefiles'
Unclear why
build()
implements its own logic, rather than at most runningCMAKEARGS="${_cmake_options[*]}" MAKEARGS=--no-silent bash ./make.sh build
That
package()
does so is more understandable, given the invocation ofsudo
inmake.sh install
Missing dependency: readline
1 2 Next › Last »