Re: New package: faust-2.20.2

[voidlinux-github@inbox.vuxu.org]

[-- Attachment #1: Type: text/plain, Size: 4377 bytes --]

New comment by DavideMaggio on void-packages repository

https://github.com/void-linux/void-packages/pull/17568#issuecomment-569409047

Comment:
> The template looks ok to me, good work!
> 

Great! Thank you very much.

<br /> 

> @DavideMaggio
> I have no idea how to test this, does it work as expected?
>

To test the Faust compiler just pick one example (/usr/lib/faust/examples/) and run: 'faust [example].dsp'.

I've also tested some scripts: faust2alsa, faust2jack, faust2alqt, faust2jaqt with some examples (also with my faust sources) and everything seems to work well to me.


<br /> 

> The android stuff in specific?
>

Unfortunately the android stuff only works in 'non-musl' systems.

with an **x86_64** system: 
```
$ faust2android freeverb.dsp 
Note: Some input files use or override a deprecated API. 
Note: Recompile with -Xlint:deprecation for details. 
freeverb.apk; 

$ ls -l 
total 2024 
-rw-r--r-- 1 mag mag     200 Dec 24 10:21 fdnRev.dsp 
-rw-r--r-- 1 mag mag 2047855 Dec 28 10:39 freeverb.apk    <--- Android package 
-rw-r--r-- 1 mag mag     173 Dec 24 10:21 freeverb.dsp
-rw-r--r-- 1 mag mag     307 Dec 24 10:21 reverbDesigner.dsp
-rw-r--r-- 1 mag mag     205 Dec 24 10:21 reverbTester.dsp
-rw-r--r-- 1 mag mag     239 Dec 24 10:21 zitaRev.dsp
-rw-r--r-- 1 mag mag     217 Dec 24 10:21 zitaRevFDN.dsp
```

with an **x86_64-musl** system:

```
$ faust2android freeverb.dsp

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':app'.
> Unable to get the CMake version located at: /opt/android/sdk/cmake/3.6.4111459/bin

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get f
ull insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 1m 4s
```

...
```
$ ldd /opt/android/sdk/cmake/3.6.4111459/bin/cmake
        /lib64/ld-linux-x86-64.so.2 (0x7fc7234b3000)
        libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7fc7234b3000)
        libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fc7234b3000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fc7234b3000)
Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /opt/android/sdk/cmake/3.6.4111459/bin/cmake)

```

The 'procedure' I actually use to test 'faust2android' is something like this:

 - `xbps-install -S unzip openjdk faust`
 - `mkdir -p /opt/android/sdk`
 - [... download Android SDK and NDK. Unpack them in /opt/android ...]
 - `cd /opt/android && mv tools sdk/ && ln -s android-ndk-[VERSION] ndk`
 - `/opt/android/sdk/tools/bin/sdkmanager --install 'platforms;android-27'`
 - `/opt/android/sdk/tools/bin/sdkmanager --install 'build-tools;28.0.3'`
 - `yes | /opt/android/sdk/tools/bin/sdkmanager --licenses`
 - `cd /usr/lib/faust/examples/reverb && faust2android freeverb.dsp`



<br />

> Is this ready to merge?
>

I think there's something we need to discuss prior to merge... try to explain myself:

The faust compiler produces a C++ optimized source code that has to be compiled with gcc. The various scripts called 'faust2...' do this work, they build an executable.. or an apk package, or a Pure Data external, or a Supercollider object, or a pdf file, etc...

So there are many possibilites:

- faust2alsa builds an executable using alsa lib with a Gtk GUI
- faust2alqt builds an executable using alsa lib with a Qt GUI
- faust2jack builds an executable using the Jack sound system lib with a Gtk GUI
- faust2puredata  builds a Pure Data external
- ...etc... (for an almost complete list see: https://github.com/grame-cncm/faust/tree/master-dev/tools/faust2appls)

But, every script needs his own 'build dependencies' or it will fail.

Example:
 To build a faust source using the 'faust2alsa' script we also need some other void packages: alsa-lib-devel, pkg-config, gtk+-devel and obviously gcc.

My question is: should we include those packages as 'faust dependencies'?

I think is not a good idea, cause this way we should consider all the 'faust2*...' scripts and include tons of libs and tools that the faust programmers will never use. Faust programmers usually use only one script depending on the needs of the application they are writing. What do you think about it?