Alternative single-executable mode

[fpesari]

Hello,

right now, CDP operates as it traditionally does, by having a separate executable file for each command.

This is very uncommon on *NIX systems and ends up cluttering a bit the program namespace, which could cause conflicts between different programs with the same name as one of the CDP commands (and with 148 programs, I think the chance of it happening is rather high!). This could create huge problems especially considering that some commands use common words such as filter, prefix and synth.

My proposed solution is to allow building CDP as a single executable which can be used like this:

cdp7 [command] [parameters]

for example

cdp7 distort ...

(I used cdp7 instead of cdp to avoid conflicts with other programs named cdp, and also so that if cdp8 is ever released and it breaks the ABI, existing user scripts won't be broken).

This could be set as a CMake option, just to avoid breaking existing user scripts based on the current way of doing things.

[fpesari]

An easier to implement (but less elegant) alternative would be to allow prepending a cdp7 prefix to all binaries, like this:

cdp7-abfdcode
cdp7-abfpan
cdp7-abfpan2
...

This still clutters the program namespace but at least there is no risk of conflicts with existing programs.

[musger]

Same thing here. I have thought about a single cdp command with the exact same syntax a while ago. It could have nice wrappers such as: Autocomplete(!), automatic conversion of time-domain and spectral files when needed, a flag to allow overwriting of output files, and who knows, even an extra command which opens the html documentation in a web browser. I only have tried doing this as a sketch wrapper shell script so far. It would be great to hear more oppinions, possibly on the mailing list. One thing to keep in mind though is to preserve the ability to run (others or historic) shell scripts with cdp commands in them and there might be many users and CDP developers even who prefer the way it is right now. I know of at least one user on the Mailinglist who has discussed the idea of a single command in the last year (on the web forum then).

Me, I have chosen to prefix all CDP binaries on Linux with cdp_ as follows:
Binaries live in ~/bin/cdpl and are symlinked with prefix to ~/bin using the following command in ~/bin
for a in cdpl/*; do ln -s "$a" cdp_"``basename $a``"; done
BEWARE that the double backticks around basename should only be single backticks, had to put them in to avoid formatting errors here. Basically it is a matter of moving the binaries out of the way (out of $PATH) but keeping them intact to allow older scripts to function still.

[richarddobson]

This is not something we could consider for the main distribution. The current set of programs is long established, and the principal GUI front ends Soundloom and SoundShaper are dependent on them. Indeed much of the code is expressly designed to work with Soundloom. There is one known name conflict - "sndinfo", which clashes with the Csound utility of the same name. It is always possible to rename any program (directly or as part of a copy). In the standard distribution, programs are not placed in general directories such as /usr/local/bin, but kept inside the top level "cdpr7" directory tree that also includes all the supoport files for Soundloom. CDP was conceived very much as a collaborative system inviting any independent developer to contribute programs to the system. While that is far less of a concern these days, the principle still holds, and we would not want to "centralise" the system to the extend of forming a single huge binary. Of course, anyone forming a complete fork can do what they like, but the CDP repository itself will need to retain its current form. Richard Dobson

…

On 13/04/2020 10:18, Fabio Pesari wrote: Hello, right now, CDP operates as it traditionally does, by having a separate executable file for each command. This is very uncommon on *NIX systems and ends up cluttering a bit the program namespace, which could cause conflicts between similar programs with the same name as one of the CDP commands. This could create huge problems since some commands use common words such as |filter|, |prefix| and |synth|. My proposed solution is to allow building CDP as a single executable which can be used like this: |cdp7 [command] [parameters]| for example |cdp7 distort ...| (I used |cdp7| instead of |cdp| to avoid conflicts with other programs named |cdp|, and also so that if cdp8 is ever released and it breaks the ABI, existing programs won't be broken). This could be set as a CMake option, just to avoid breaking existing scripts based on the current way of doing things. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#12>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABNHS4UHPFFP2VQQD775DVLRMLKG3ANCNFSM4MG2SHOA>.

[fpesari]

Hello Prof. @richarddobson,

first, thanks for all your work! :D

That said, in my original post, I didn't ask for a single executable by default, just for an optional CMake directive for those who need it. Even a prefix cdp7- or cdp7_ would be enough.

I made a CDP package for openSUSE (https://build.opensuse.org/package/show/home:ozu/CompostersDesktopProject), but I can't really push it to the main repository if there is a risk of breaking someone's setup, since openSUSE's package manager uses /usr/bin. Mine is not a philosophical or aesthetic stance then, it's simply my concern as a packager who'd like to get CDP on as many musicians' machines as possible :)

[musger]

The soundloom and soundshaper GUIs for CDP are not available on Linux to my knowledge, hence installing binaries in /usr/bin should not do any harm. I further find a possible prefix should not include a version number such as "7" as these do change over time. Fabio, are you packaging for other Linux distributions than openSUSE as well?

[fpesari]

Fabio, are you packaging for other Linux distributions than openSUSE as well?

I think the .spec should (more or less) work on Fedora, I never learned to make packages for non-RPM distros, sorry 😞