Package Details: sxiv-git 2016.08.08-1

Git Clone URL: https://aur.archlinux.org/sxiv-git.git (read-only)
Package Base: sxiv-git
Description: Simple (or small or suckless) X Image Viewer
Upstream URL: https://github.com/muennich/sxiv
Licenses: GPL2
Conflicts: sxiv
Provides: sxiv
Submitter: None
Maintainer: jasonwryan
Last Packager: jasonwryan
Votes: 31
Popularity: 0.043462
First Submitted: 2011-01-23 13:55
Last Updated: 2016-08-10 07:16

Dependencies (5)

Required by (2)

Sources (1)

Latest Comments

jasonwryan commented on 2017-02-02 20:01

cutuchiqueno I just create a separate branch that contains my config.h and then I can git pull from here without overwriting that file, checkout that branch and then build against head and my customisations are applied.

cutuchiqueno commented on 2017-02-02 09:40

can you explain quickly how to use a custom config.h while using this PKGBUILD? I had a log at the file but did not understand it enough to get the information out of it and also searched the corresponding forum without finding the necessary information. Thx.

jasonwryan commented on 2016-08-10 07:19

Thanks sekret: updated.

sekret commented on 2016-08-10 05:48

Hey Jason, please make some changes to the PKGBUILD:

Remove the install file. It's not needed anymore, because it does, what now hooks do. Namcap will show you this aswell.

Please change the depends line to

depends=('imlib2' 'libexif' 'libxft' 'hicolor-icon-theme')

This was done by reading namcap's output. Especially libxft is absolutely required, the package doesn't even build without it!

mkoskar commented on 2014-10-24 11:25

@jasonwryan: I see, I've missed that info in man page. Good to know. Ok no problem, I maintain my clone anyway because of 'config.h', just wanted to minimize tweaks I do. Still though, I'm wondering if there is another, more suitable way how to do this. Probably is not very common use case. Thanks ;)

jasonwryan commented on 2014-10-24 09:27

@mkoskar given that $startdir is deprecated and its use "strongly discouraged" (man pkgbuild), I am inclined to leave things as they are for the time being. I agree it is not ideal, but it sucks the least, as far as I can tell.

mkoskar commented on 2014-10-24 07:54

@jasonwryan: Sorry for late response ... I don't think there are any advantages per se, but if you think of it SRCDEST doesn't make sense here really I believe, because the 'config.h' in this case is not a 'source' file (otherwise it would be listed in source array). In fact it's a kind of trick when build "depends" on something outside of regular sources (which normally shouldn't be the case). So we can either pretend it's a source and say packager has to ensure to copy it into SRCDEST (or $srcdir in that case is more correct), or we say it's not source at all and rather it is something living somewhere else. I've suggested BUILDDIR because it was working for me, but realized it can be changed too an it is probably frequent use-case? I've did some testing now, and found out that regardless where SRCDEST and BUILDDIR are pointing $startdir always points to original location from which `makepkg` is run, so I think it is reasonable and justified to use $startdir here. It could be that there is some better solution to this though ;).

jasonwryan commented on 2014-10-18 06:55

@mkoskar What advantage is there to preferring BUILDDIR over SRCDEST (apart from in your case)? The VCS guidelines seem to prefer the former: https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines#VCS_sources

mkoskar commented on 2014-10-16 18:32

@jasonwryan: I've found out that $SRCDEST doesn't work for me since I have set it to point to global cache directory. Figured out that $BUILDDIR is want we want. If you fancy you can grab fixed version ($SRCDEST -> $BUILDDIR, + removing some trailing whitespace) from <https://raw.githubusercontent.com/mkoskar/pkgbuilds/master/sxiv-git/PKGBUILD>. Thanks!

jasonwryan commented on 2014-10-12 06:53

Thanks sekret. I'm going to leave things as they are for the time being; I appreciate the suggestions, but unless there is something particularly broken about this approach, I see no compelling reason to change it.

All comments