You are not logged in.
Is there a chance a makepkg patch to support a clean() method in PKGBUILDs would be accepted?
Rationale: I'm building a bunch of packages that mostly contain Java using maven. Maven has its own conventions, including to put build artifacts into directory ./target. It would make my life easier if makepkg -c could clean up the content of the target directory/ies, and I figure the easiest way of doing that would be to allow for a PKGBUILD method like this:
clean() {
\rm -rf ${startdir}/somedir/target
}
It appears the patch would be quite small, basically adding to the cleanup code:
if have_function clean; then
run_function_safe "clean"
fi
The counter-argument would probably be that takes makepkg into the direction of a general-purpose project build tool, which not everybody might like.
Thoughts?
Offline
Sounds like you want makepkg -C
Online
The problem is that the maven hierarchy is not below $srcdir. Well, not all of it and not all of the time.
I'm sort of asking for the opposite of prepare().
Offline
So you're working outside of $srcdir? You'd have to make assumptions about $startdir for that to work, and last I knew that wasn't guaranteed. Sounds like a bad idea all around.
Online
I realize I'm stepping outside of the current assemptions by just a bit, which is why I'm asking so carefully :-) On the other hand, the change appears so small, does not look it would get into anybody's way, and might be useful for others, so I figure I ask.
Offline
Why would you work outside of $srcdir? Are you trying to have the PKGBUILD in the same source tree as your code? It is not designed for that. Your maven "src" should be a subdirectory of "$srcdir" and not the same path.
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
First, the existing functions in the PKGBUILD should not be putting anything anywhere outside of srcdir and pkgdir. Period. [There is a de facto convention whereby some PKGBUILDs will check for a file (e.g. a config.h) outside these directories and cp it in, but even that is sometimes controversial and yet quite different from moving stuff out of these directories.]
So as noted above, fix the problematic PKGBUILD, don't try to work around the existing brokenness by adding more. If you want help doing that, post the offending PKGBUILD here.
That said, even if the PKGBUILD is to continue doing what it does now, there'd be no need for a separate clean function: just clean up any mess made by the build/package functions in the package function. There'd be no harm in (trying to) run an "rm -rf /path/to/outside-of/srcdir-or-pkgdir" inside the package function as nothing outside of pkgdir is used for building the package (delete it all!).
That said, if I ever see a PKGBUILD with your name on it that tries to run an "rm -rf" anywhere outside of srcdir or pkgdir do not be surprised if you find a flaming bag of dog poop at your front door.
Last edited by Trilby (2017-11-16 00:02:26)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Ok guys, fair enough. You have defined a clear line of what is acceptable and what not, and while we can argue whether it's the right line or not, I'm all in favor of clear lines, so I withdraw the request.
Offline
Any software so ugly that it doesn't know how to keep it inside the build directory, can probably be forced into doing so anyway by judicious use of `export HOME="$srcdir"` right before building. But preferably, the build system would allow you to specify at the very least through a config option, where to store files.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline