[aur-general] TU Application: Daniel Bermond (dbermond)

Daniel Bermond danielbermond at gmail.com
Mon Oct 15 02:59:58 UTC 2018

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20181014/5a287171/attachment.asc>

More information about the aur-general mailing list