On 10/14/18 7:06 PM, Eli Schwartz via aur-general wrote:
That's a rather... intimidatingly complex Makefile, by the way. If I might ask, what is the purpose of splitting apart the source files then recombining them like this? It is slightly similar to how makepkg is developed, except we loop through and source a library in /usr/share/makepkg ...
Carving apart the headers with sed and relying on the *order* they are combined, seems to be defeating the purpose at any rate.
The purpose is to have a single script as the final result, instead of an executable with installed modules. And yes, using 'source' (the dot command) was discarded by me during development, so a makefile with split sources was the choice, being it complex or not. ;) Since the final script is huge, this make it easier to use and distribute it (it's just a single file), while making it possible to split the source code into separated parts for easier maintenance in the future, specially if the code keeps growing up. When having such a large script in a single file, it keeps harder and harder to maintain/fix/improve the code, so I decided to make this way.
...
The Makefile specifies various targets using e.g. PREFIX := /usr/local, surely you meant to use ?= for this? BCOMPDIR should properly be derived from $(shell pkg-config bash-completion --variable completionsdir)
Thanks for the suggestions. :)
Your other loops here and there could take advantage of *not* being loops, like for make clean, just using rm's builtin -v to print the files being removed.
Make clean just erases a single file (screencast) if it is present, without looping. Even if it was looping, in this way a get a personalized output message instead of the standard rm message, which I like ;). And this is not a critical part to worry about loops :)
I also find it rather odd that you take pains to single-quote your static strings in sh snippets like [ -f '$(NAME)' ] and [ -d './test/output' ]
I like to quote things in shell code (the part you mentioned are shell ones). That's just my personal approach. You can see this on the .sh sources too.
But, you don't quote things that need quoting, like: install -Dm755 ... '$(DESTDIR)'...
(Because DESTDIR can have spaces depending on the makepkg BUILDDIR, hence why we always quote "$srcdir" and "$pkgdir", at least until the Makefile mangles it for us.)
Ah yes, forgot it there. Thanks for pointing this out! :)
Don't feel bad though, you're nowhere near the only offender at this -- GNU autotools does it too, so most Makefiles in the world have this issue.
I also see this out there ;)
You probably should not be opinionated in your Makefile, about gzipping the manpage. Packaging tools like makepkg already do this (and maybe make it configurable). I would say it breaks reproducible builds, but you did add the -n flag so at least that is alright.
The purpose of this makefile was to present the regular user with a proper and well suited installation. If you check the readme it has an installation section with very basic instructions. Being such, for the regular user perspective it's better to install a gzipped manpage. Packagers can modify this at their will.
I would like to bring the following packages into [community]: - advancecomp Too late -- I said I would do that back in my TU application: https://lists.archlinux.org/pipermail/aur-general/2017-December/033719.html
And you've reminded me to do so. :p
Oh sorry, I missed you saying this about advancecomp :) -- Best regards, Daniel Bermond