guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#69593] Add FluidPlug


From: Gabriel Wicki
Subject: [bug#69593] Add FluidPlug
Date: Tue, 26 Nov 2024 22:04:52 +0100

Hi Giacomo!

First of all, thanks for this amazing patch and sorry for the long
delay.

A few assorted comments to your commit messages: 
 - fluidplug-plugin->package is a function, not a variable.
 - you can sum the list of variables in the commit message like so:

(fluidplug-airfont320-lv2, fluidplug-avl-drumkits-perc-lv2,
fluidplug-black-pearl-4a-lv2, ...): New variables.

To the package definitions: great job!  I like how you simplified the
definitions and create them programmatically!  Really cool!

A couple of comments I do have, though:
 - I personally wouldn't mix #:exports and define-public in the same
   file - not sure whether there's some sort of Guix (or Guile)-wide
   consensus on the issue.

 - You might want to omit the "-fluidplug-plugin" part in each of the
   plugin variable names.  You do not export those names so I think you
   can save some of these bytes (:

 - Did you consider cross compilation?  I've tried some rather naively,
   but failed.  Also building for aarch64 (natively) failed.  Is this
   package not supposed to work on other architectures except amd64?  If
   that is the case, please specify it

 - Changing env var CC= should happen within the #:make-flags block
   instead of its own build phase.  And it shouldn't hard-code "gcc" but
   rather #$(cc-for-target) to allow for cross-compilation.

 - I think lv2 should be in `inputs', not in `native-inputs' (again,
   considering cross-compilation) of the fluidplug-lv2 package.


Since I can not commit merging still needs some work by someone else.
But except for the lack of cross-compilation (and foreign native
compilation) I do not see any show-stoppers.

Have a nice week!

gabber





reply via email to

[Prev in Thread] Current Thread [Next in Thread]