Freeze zum ersten Release

[cwh]

Hi,

Warum man ggf. das mitgelieferter jthread nutzen sollte / können sollte ? Naja. Weil es unter Windows kein vorinstalliertes gibt ... :)

Öhm, man bekommt die libs da nicht irgendwie als dlls hin?

Ich denke die lame Quelltexte werde ich demnächst mal aus dem Repository rausnehmen und stattdessen den leeren Ordner als Platzhalter drin lassen. Damit sollte man die lizenzrechtlichen Probleme umgehen können.

Die Probleme hat man eigentlich nur als Distributor. Damit verhindert man also nur, daß man mal auf einer Distri landet bzw. in meinem konkreten Fall, daß man es im openSUSE Buildservice bauen kann. Und letzteres ist zur Bereitstellung von Binärpaketen für die gängigen Distributionen eine sagenhafte Arbeitserleichterung.

Oder man ergänzt die Plugininfo noch mit dem verbundenen Kanal. Dann würde es wieder Sinn machen. Da bisher nur der Audiorekorder interessant ist kann man auch einfach nur eine Aufnahme versuchen. Wenn der monitord dann meckert ist kein audioplugin installiert.

So mach ich das bisher auch und damit komm ich auch zurecht. Allerdings wäre die Info schon besser in der Kanalinfo afgehoben, denke ich.

Die Korrektur ist bestimmt sinnvoll. Wobei ich bei einer config datei die man wohl eher nie mit einer DCD segnen oder auch mal transformieren will das nicht so dramatisch sehe :) Dennoch sollte man da natürlich auch versuchen sich an die Standards zu halten.

Ist schon behoben. Ich würde die Linux Beispielconfig übrigens auch noch gerne mit Unix statt DOS Lineendings ausstatten. Das gibt aber dann einen 100%-diff.

Die Pfade relativ anzugeben halte ich auch für sinnvoll. Ich könnte mir da z.B. auch einfach einen PluginOrdner Parameter vorstellen (Entweder absolut oder relativ zum aktuellen Verzeichnis). Zum Thema Endungen: Da würde ich einfach erst dem Dateinamen als solches Versuchen und dann unter win32 ein .dll ergänzen. Unter linux ein .so . Damit wäre das Ziel der Portabilität der config files in Deinem Sinne erreicht, oder ?

Ich würde Pfade und Endung mit Präprozessorkommandos zur compiletime festlegen. Configure weiß alles, was man dazu braucht, heißt: den libpath und die Plattform.

Wenn konfiguriert ist, dann sollte erst geguckt werden, ob das geladen werden kann, wenn fehlt, dann würde einfach wie folgt ein Filename zusammenstöpselt werden:

LIBPATH/libmplugin_PLUGINNAME.SUFFIX

Ich würde das mal versuchen einzubauen, wenn keiner was dagegen hat.

Ich merke, daß cwh das ganze unter linux anwendet. Somit sieht er es natürlich mehr die Bedürfnisse, die da vorherrschen. Meistens ist das deckungsgleich oder unabhängig zum win32 System. Sollte dem nicht so sein sollten wir immer versuchen - so wie bisher auch - eine Lösung zu finden, die auf beiden Systeme arbeitet. Ich nutze msys ja nicht, weil es so besonders komfortabel ist sondern um möglichst wenig Einzelanpassungen pro System machen zu müssen.

Zum thema libtool könnte ich inzwischen vermutlich Bücher schreiben. Nicht, weil ich sie verstanden habe sondern weil es einfach ständig was zu meckern hat. Wer Zeit hat kann ja mal versuchen das sox v14 mit dem plugins unter msys zu kompilieren. Und dann auch noch zu seinem Programm zu linken ...

Ich werde irgendwann nochmal Visual C installieren und dann da die dll erstellen. Alles andere ist furchtbar.

Ja, ich verwende monitord ausschließlich unter Linux, daher weiß ich auch nicht um die Fallstricke, die man hat, wenn man das ganze versucht unter Windows zu bauen. Gibt es sox etc. nicht evtl einfach fertig gebaut für mingw?

Unter Linux baut monitord inzwischen ja einfach und problemlos durch.

Grüße,
Christopher