Csound Csound-dev Csound-tekno Search About

[Csnd-dev] plugins repository

Date2019-11-18 20:01
FromMichael Gogins
Subject[Csnd-dev] plugins repository
I think having a plugins repository is a great idea. Currently, the
Python opcodes reside at the top level of the plugins tree. Shouldn't
each plugin have its own directory in the repository?

Then a master CMakeLists.txt could simply include a subdirectory for
each plugin's own CMakeLists.txt.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

Date2019-11-18 20:21
FromFrancois PINOT
SubjectRe: [Csnd-dev] plugins repository
Hi Mike,

for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.

Regards

François

Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
I think having a plugins repository is a great idea. Currently, the
Python opcodes reside at the top level of the plugins tree. Shouldn't
each plugin have its own directory in the repository?

Then a master CMakeLists.txt could simply include a subdirectory for
each plugin's own CMakeLists.txt.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

Date2019-11-18 20:22
FromVictor Lazzarini
SubjectRe: [Csnd-dev] plugins repository
I think that is the ideal directory layout alright. 

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:02, Michael Gogins  wrote:
> 
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
> 
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
> 
> Regards,
> Mike
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com

Date2019-11-18 21:53
FromMichael Gogins
SubjectRe: [Csnd-dev] plugins repository
Ok, that's how I think it should be. I thought py was a subdir of the Python opcodes repo.

Regards, 
Mike

On Mon, Nov 18, 2019, 12:22 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
I think that is the ideal directory layout alright.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:02, Michael Gogins <michael.gogins@gmail.com> wrote:
>
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
>
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com

Date2019-11-19 12:38
FromVictor Lazzarini
SubjectRe: [Csnd-dev] plugins repository
I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add

add_subdirectory(...)

to it and have a simple CMakeLists.txt in the directory.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:21, Francois PINOT  wrote:
> 
> Hi Mike,
> 
> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
> 
> Regards
> 
> François
> 
> Le lun. 18 nov. 2019 à 21:01, Michael Gogins  a écrit :
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
> 
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
> 
> Regards,
> Mike
> 
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com


Date2019-11-19 12:50
FromRory Walsh
SubjectRe: [Csnd-dev] plugins repository
So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?

On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add

add_subdirectory(...)

to it and have a simple CMakeLists.txt in the directory.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>
> Hi Mike,
>
> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>
> Regards
>
> François
>
> Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
>
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com


Date2019-11-19 12:52
FromRory Walsh
SubjectRe: [Csnd-dev] plugins repository
Also, I can add an Azure pipelines build for those who don't want to build themselves. But I'm not sure if the Csound project has an account there? I've only ever used Azure for personal builds. 

On Tue, 19 Nov 2019 at 12:50, Rory Walsh <rorywalsh@ear.ie> wrote:
So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?

On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add

add_subdirectory(...)

to it and have a simple CMakeLists.txt in the directory.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>
> Hi Mike,
>
> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>
> Regards
>
> François
>
> Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
>
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com


Date2019-11-19 13:13
FromFrancois PINOT
SubjectRe: [Csnd-dev] plugins repository
Maybe keep this level for historical plugins which are actually in core Csound, and then apply your proposal for new plugins?

François

Le mar. 19 nov. 2019 à 13:50, Rory Walsh <rorywalsh@ear.ie> a écrit :
So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?

On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add

add_subdirectory(...)

to it and have a simple CMakeLists.txt in the directory.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>
> Hi Mike,
>
> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>
> Regards
>
> François
>
> Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
>
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com


Date2019-11-19 13:14
FromVictor Lazzarini
SubjectRe: [Csnd-dev] plugins repository
yes, for every plugin lib.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 19 Nov 2019, at 12:50, Rory Walsh <rorywalsh@ear.ie> wrote:

So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?

On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add

add_subdirectory(...)

to it and have a simple CMakeLists.txt in the directory.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>
> Hi Mike,
>
> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>
> Regards
>
> François
>
> Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
>
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com


Date2019-11-19 14:57
FromMichael Gogins
SubjectRe: [Csnd-dev] plugins repository
Thanks. Simple and straightforward. 

The question about submodules is good. Moving or deleting them can be a pain.

I also wonder about support for multiple platforms. 

Regards, 
Mike

On Tue, Nov 19, 2019, 05:14 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
yes, for every plugin lib.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 19 Nov 2019, at 12:50, Rory Walsh <rorywalsh@ear.ie> wrote:

So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?

On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add

add_subdirectory(...)

to it and have a simple CMakeLists.txt in the directory.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>
> Hi Mike,
>
> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>
> Regards
>
> François
>
> Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
>
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com


Date2019-11-19 16:11
FromRory Walsh
SubjectRe: [Csnd-dev] plugins repository
That's a good point about platforms. Might I suggest that all opcodes pushed to this repo must build on the three major platforms? 

On Tue, 19 Nov 2019 at 14:57, Michael Gogins <michael.gogins@gmail.com> wrote:
Thanks. Simple and straightforward. 

The question about submodules is good. Moving or deleting them can be a pain.

I also wonder about support for multiple platforms. 

Regards, 
Mike

On Tue, Nov 19, 2019, 05:14 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
yes, for every plugin lib.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 19 Nov 2019, at 12:50, Rory Walsh <rorywalsh@ear.ie> wrote:

So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?

On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add

add_subdirectory(...)

to it and have a simple CMakeLists.txt in the directory.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>
> Hi Mike,
>
> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>
> Regards
>
> François
>
> Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
>
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com


Date2019-11-19 16:18
FromFrancois PINOT
SubjectRe: [Csnd-dev] plugins repository
Absolutely

François

Le mar. 19 nov. 2019 à 17:11, Rory Walsh <rorywalsh@ear.ie> a écrit :
That's a good point about platforms. Might I suggest that all opcodes pushed to this repo must build on the three major platforms? 

On Tue, 19 Nov 2019 at 14:57, Michael Gogins <michael.gogins@gmail.com> wrote:
Thanks. Simple and straightforward. 

The question about submodules is good. Moving or deleting them can be a pain.

I also wonder about support for multiple platforms. 

Regards, 
Mike

On Tue, Nov 19, 2019, 05:14 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
yes, for every plugin lib.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 19 Nov 2019, at 12:50, Rory Walsh <rorywalsh@ear.ie> wrote:

So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?

On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add

add_subdirectory(...)

to it and have a simple CMakeLists.txt in the directory.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>
> Hi Mike,
>
> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>
> Regards
>
> François
>
> Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
>
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com


Date2019-11-19 16:22
FromSteven Yi
SubjectRe: [Csnd-dev] plugins repository
We should seek to add support for non-desktop platforms as well. (Web
and Android, others)

On Tue, Nov 19, 2019 at 11:11 AM Rory Walsh  wrote:
>
> That's a good point about platforms. Might I suggest that all opcodes pushed to this repo must build on the three major platforms?
>
> On Tue, 19 Nov 2019 at 14:57, Michael Gogins  wrote:
>>
>> Thanks. Simple and straightforward.
>>
>> The question about submodules is good. Moving or deleting them can be a pain.
>>
>> I also wonder about support for multiple platforms.
>>
>> Regards,
>> Mike
>>
>> On Tue, Nov 19, 2019, 05:14 Victor Lazzarini  wrote:
>>>
>>> yes, for every plugin lib.
>>>
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>>
>>> On 19 Nov 2019, at 12:50, Rory Walsh  wrote:
>>>
>>> So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?
>>>
>>> On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini  wrote:
>>>>
>>>> I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add
>>>>
>>>> add_subdirectory(...)
>>>>
>>>> to it and have a simple CMakeLists.txt in the directory.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>>
>>>> > On 18 Nov 2019, at 20:21, Francois PINOT  wrote:
>>>> >
>>>> > Hi Mike,
>>>> >
>>>> > for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>>>> >
>>>> > Regards
>>>> >
>>>> > François
>>>> >
>>>> > Le lun. 18 nov. 2019 à 21:01, Michael Gogins  a écrit :
>>>> > I think having a plugins repository is a great idea. Currently, the
>>>> > Python opcodes reside at the top level of the plugins tree. Shouldn't
>>>> > each plugin have its own directory in the repository?
>>>> >
>>>> > Then a master CMakeLists.txt could simply include a subdirectory for
>>>> > each plugin's own CMakeLists.txt.
>>>> >
>>>> > Regards,
>>>> > Mike
>>>> >
>>>> > -----------------------------------------------------
>>>> > Michael Gogins
>>>> > Irreducible Productions
>>>> > http://michaelgogins.tumblr.com
>>>> > Michael dot Gogins at gmail dot com
>>>>

Date2019-11-19 16:28
FromRory Walsh
SubjectRe: [Csnd-dev] plugins repository
The next question I have is whether the existing opcode plugins that have been spawned out, i.e, csladspa, csound~ etc, should all now form submodules of this repo? It would make things cleaner right? 

On Tue, 19 Nov 2019 at 16:22, Steven Yi <stevenyi@gmail.com> wrote:
We should seek to add support for non-desktop platforms as well. (Web
and Android, others)

On Tue, Nov 19, 2019 at 11:11 AM Rory Walsh <rorywalsh@ear.ie> wrote:
>
> That's a good point about platforms. Might I suggest that all opcodes pushed to this repo must build on the three major platforms?
>
> On Tue, 19 Nov 2019 at 14:57, Michael Gogins <michael.gogins@gmail.com> wrote:
>>
>> Thanks. Simple and straightforward.
>>
>> The question about submodules is good. Moving or deleting them can be a pain.
>>
>> I also wonder about support for multiple platforms.
>>
>> Regards,
>> Mike
>>
>> On Tue, Nov 19, 2019, 05:14 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>
>>> yes, for every plugin lib.
>>>
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>>
>>> On 19 Nov 2019, at 12:50, Rory Walsh <rorywalsh@ear.ie> wrote:
>>>
>>> So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?
>>>
>>> On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>>
>>>> I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add
>>>>
>>>> add_subdirectory(...)
>>>>
>>>> to it and have a simple CMakeLists.txt in the directory.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>>
>>>> > On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>>>> >
>>>> > Hi Mike,
>>>> >
>>>> > for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>>>> >
>>>> > Regards
>>>> >
>>>> > François
>>>> >
>>>> > Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
>>>> > I think having a plugins repository is a great idea. Currently, the
>>>> > Python opcodes reside at the top level of the plugins tree. Shouldn't
>>>> > each plugin have its own directory in the repository?
>>>> >
>>>> > Then a master CMakeLists.txt could simply include a subdirectory for
>>>> > each plugin's own CMakeLists.txt.
>>>> >
>>>> > Regards,
>>>> > Mike
>>>> >
>>>> > -----------------------------------------------------
>>>> > Michael Gogins
>>>> > Irreducible Productions
>>>> > http://michaelgogins.tumblr.com
>>>> > Michael dot Gogins at gmail dot com
>>>>

Date2019-11-19 19:07
FromVictor Lazzarini
SubjectRe: [Csnd-dev] plugins repository
csladspa and csound~ are frontends, and have their own repos.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 19 Nov 2019, at 16:26, Rory Walsh <rorywalsh@ear.ie> wrote:

The next question I have is whether the existing opcode plugins that have been spawned out, i.e, csladspa, csound~ etc, should all now form submodules of this repo? It would make things cleaner right? 

On Tue, 19 Nov 2019 at 16:22, Steven Yi <stevenyi@gmail.com> wrote:
We should seek to add support for non-desktop platforms as well. (Web
and Android, others)

On Tue, Nov 19, 2019 at 11:11 AM Rory Walsh <rorywalsh@ear.ie> wrote:
>
> That's a good point about platforms. Might I suggest that all opcodes pushed to this repo must build on the three major platforms?
>
> On Tue, 19 Nov 2019 at 14:57, Michael Gogins <michael.gogins@gmail.com> wrote:
>>
>> Thanks. Simple and straightforward.
>>
>> The question about submodules is good. Moving or deleting them can be a pain.
>>
>> I also wonder about support for multiple platforms.
>>
>> Regards,
>> Mike
>>
>> On Tue, Nov 19, 2019, 05:14 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>
>>> yes, for every plugin lib.
>>>
>>> Prof. Victor Lazzarini
>>> Maynooth University
>>> Ireland
>>>
>>> On 19 Nov 2019, at 12:50, Rory Walsh <rorywalsh@ear.ie> wrote:
>>>
>>> So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?
>>>
>>> On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>>
>>>> I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add
>>>>
>>>> add_subdirectory(...)
>>>>
>>>> to it and have a simple CMakeLists.txt in the directory.
>>>> ========================
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>>
>>>> > On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>>>> >
>>>> > Hi Mike,
>>>> >
>>>> > for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>>>> >
>>>> > Regards
>>>> >
>>>> > François
>>>> >
>>>> > Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
>>>> > I think having a plugins repository is a great idea. Currently, the
>>>> > Python opcodes reside at the top level of the plugins tree. Shouldn't
>>>> > each plugin have its own directory in the repository?
>>>> >
>>>> > Then a master CMakeLists.txt could simply include a subdirectory for
>>>> > each plugin's own CMakeLists.txt.
>>>> >
>>>> > Regards,
>>>> > Mike
>>>> >
>>>> > -----------------------------------------------------
>>>> > Michael Gogins
>>>> > Irreducible Productions
>>>> > http://michaelgogins.tumblr.com
>>>> > Michael dot Gogins at gmail dot com
>>>>

Date2019-11-19 19:09
FromVictor Lazzarini
SubjectRe: [Csnd-dev] plugins repository
yes.

But I should say now that I probably misunderstood the point about submodules.

Not sure what this means actually.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 19 Nov 2019, at 16:22, Steven Yi  wrote:
> 
> We should seek to add support for non-desktop platforms as well. (Web
> and Android, others)
> 
>> On Tue, Nov 19, 2019 at 11:11 AM Rory Walsh  wrote:
>> 
>> That's a good point about platforms. Might I suggest that all opcodes pushed to this repo must build on the three major platforms?
>> 
>>> On Tue, 19 Nov 2019 at 14:57, Michael Gogins  wrote:
>>> 
>>> Thanks. Simple and straightforward.
>>> 
>>> The question about submodules is good. Moving or deleting them can be a pain.
>>> 
>>> I also wonder about support for multiple platforms.
>>> 
>>> Regards,
>>> Mike
>>> 
>>>> On Tue, Nov 19, 2019, 05:14 Victor Lazzarini  wrote:
>>>> 
>>>> yes, for every plugin lib.
>>>> 
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>> 
>>>> On 19 Nov 2019, at 12:50, Rory Walsh  wrote:
>>>> 
>>>> So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?
>>>> 
>>>>> On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini  wrote:
>>>>> 
>>>>> I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add
>>>>> 
>>>>> add_subdirectory(...)
>>>>> 
>>>>> to it and have a simple CMakeLists.txt in the directory.
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Maynooth University
>>>>> Ireland
>>>>> 
>>>>>> On 18 Nov 2019, at 20:21, Francois PINOT  wrote:
>>>>>> 
>>>>>> Hi Mike,
>>>>>> 
>>>>>> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>>>>>> 
>>>>>> Regards
>>>>>> 
>>>>>> François
>>>>>> 
>>>>>> Le lun. 18 nov. 2019 à 21:01, Michael Gogins  a écrit :
>>>>>> I think having a plugins repository is a great idea. Currently, the
>>>>>> Python opcodes reside at the top level of the plugins tree. Shouldn't
>>>>>> each plugin have its own directory in the repository?
>>>>>> 
>>>>>> Then a master CMakeLists.txt could simply include a subdirectory for
>>>>>> each plugin's own CMakeLists.txt.
>>>>>> 
>>>>>> Regards,
>>>>>> Mike
>>>>>> 
>>>>>> -----------------------------------------------------
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://michaelgogins.tumblr.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>> 

Date2019-11-19 21:22
FromMichael Gogins
SubjectRe: [Csnd-dev] plugins repository
Not a good idea at all, unless there is a continuous integration pipeline that produces release builds for all platforms.

Regards, 
Mine

On Tue, Nov 19, 2019, 08:11 Rory Walsh <rorywalsh@ear.ie> wrote:
That's a good point about platforms. Might I suggest that all opcodes pushed to this repo must build on the three major platforms? 

On Tue, 19 Nov 2019 at 14:57, Michael Gogins <michael.gogins@gmail.com> wrote:
Thanks. Simple and straightforward. 

The question about submodules is good. Moving or deleting them can be a pain.

I also wonder about support for multiple platforms. 

Regards, 
Mike

On Tue, Nov 19, 2019, 05:14 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
yes, for every plugin lib.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 19 Nov 2019, at 12:50, Rory Walsh <rorywalsh@ear.ie> wrote:

So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?

On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add

add_subdirectory(...)

to it and have a simple CMakeLists.txt in the directory.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>
> Hi Mike,
>
> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>
> Regards
>
> François
>
> Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
>
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com


Date2019-11-19 21:24
FromMichael Gogins
SubjectRe: [Csnd-dev] plugins repository
Git submodules, symlinks to other Git repos that act like subdirs in your own repo. I use many, and the csound repo is a submodule in my csound-extended repo.

Regards, 
Mike

On Tue, Nov 19, 2019, 11:09 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
yes.

But I should say now that I probably misunderstood the point about submodules.

Not sure what this means actually.

Prof. Victor Lazzarini
Maynooth University
Ireland

> On 19 Nov 2019, at 16:22, Steven Yi <stevenyi@gmail.com> wrote:
>
> We should seek to add support for non-desktop platforms as well. (Web
> and Android, others)
>
>> On Tue, Nov 19, 2019 at 11:11 AM Rory Walsh <rorywalsh@ear.ie> wrote:
>>
>> That's a good point about platforms. Might I suggest that all opcodes pushed to this repo must build on the three major platforms?
>>
>>> On Tue, 19 Nov 2019 at 14:57, Michael Gogins <michael.gogins@gmail.com> wrote:
>>>
>>> Thanks. Simple and straightforward.
>>>
>>> The question about submodules is good. Moving or deleting them can be a pain.
>>>
>>> I also wonder about support for multiple platforms.
>>>
>>> Regards,
>>> Mike
>>>
>>>> On Tue, Nov 19, 2019, 05:14 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>>
>>>> yes, for every plugin lib.
>>>>
>>>> Prof. Victor Lazzarini
>>>> Maynooth University
>>>> Ireland
>>>>
>>>> On 19 Nov 2019, at 12:50, Rory Walsh <rorywalsh@ear.ie> wrote:
>>>>
>>>> So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?
>>>>
>>>>> On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
>>>>>
>>>>> I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add
>>>>>
>>>>> add_subdirectory(...)
>>>>>
>>>>> to it and have a simple CMakeLists.txt in the directory.
>>>>> ========================
>>>>> Prof. Victor Lazzarini
>>>>> Maynooth University
>>>>> Ireland
>>>>>
>>>>>> On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>>>>>>
>>>>>> Hi Mike,
>>>>>>
>>>>>> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> François
>>>>>>
>>>>>> Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
>>>>>> I think having a plugins repository is a great idea. Currently, the
>>>>>> Python opcodes reside at the top level of the plugins tree. Shouldn't
>>>>>> each plugin have its own directory in the repository?
>>>>>>
>>>>>> Then a master CMakeLists.txt could simply include a subdirectory for
>>>>>> each plugin's own CMakeLists.txt.
>>>>>>
>>>>>> Regards,
>>>>>> Mike
>>>>>>
>>>>>> -----------------------------------------------------
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://michaelgogins.tumblr.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>

Date2019-11-19 22:46
FromStephen Kyne
SubjectRe: [Csnd-dev] plugins repository

There will be a CI pipeline though. I mentioned earlier, this could form the foundation of a package manager for opcodes. We should leverage Azure Pipelines to build on every platform and deploy the builds somewhere where the PM can pull them from.

 

I think for any small opcodes, the authors should be able to just do a PR to this official opcode repo with the source code / CMake file (maybe some kind of package/opcode definition file) and it should be added into the catalog automatically from there. That gives a low barrier for entry for people which should encourage adding content.

 

I think for bigger opcodes, sure we could add submodules that point to an external repo. The author would have to make a PR for us to up date this link in the main repo if they update their local opcode repo but that’s not a huge deal I suppose.

 

One thing to consider though, is there any concept of versioning with current opcodes? Should these built opcodes work with any past and future Csound version? How can a breaking API change be implemented?

 

Stephen

 

From: Michael Gogins
Sent: Tuesday 19 November 2019 23:30
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] plugins repository

 

Not a good idea at all, unless there is a continuous integration pipeline that produces release builds for all platforms.

 

Regards, 

Mine

 

On Tue, Nov 19, 2019, 08:11 Rory Walsh <rorywalsh@ear.ie> wrote:

That's a good point about platforms. Might I suggest that all opcodes pushed to this repo must build on the three major platforms? 

 

On Tue, 19 Nov 2019 at 14:57, Michael Gogins <michael.gogins@gmail.com> wrote:

Thanks. Simple and straightforward. 

 

The question about submodules is good. Moving or deleting them can be a pain.

 

I also wonder about support for multiple platforms. 

 

Regards, 

Mike

 

On Tue, Nov 19, 2019, 05:14 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

yes, for every plugin lib.

Prof. Victor Lazzarini

Maynooth University

Ireland


On 19 Nov 2019, at 12:50, Rory Walsh <rorywalsh@ear.ie> wrote:

So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?

 

On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add

add_subdirectory(...)

to it and have a simple CMakeLists.txt in the directory.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>
> Hi Mike,
>
> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>
> Regards
>
> François
>
> Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
>
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com

 


Date2019-11-19 23:46
FromMichael Gogins
SubjectRe: [Csnd-dev] plugins repository
Good question about API version compatibility. The policy has been AFAIK to leave existing calls in place and add new ones only at the end of the CSOUND struct, which should preserve backwards compatibility.

Regards, 
Mike

On Tue, Nov 19, 2019, 14:46 Stephen Kyne <stevek@outlook.ie> wrote:

There will be a CI pipeline though. I mentioned earlier, this could form the foundation of a package manager for opcodes. We should leverage Azure Pipelines to build on every platform and deploy the builds somewhere where the PM can pull them from.

 

I think for any small opcodes, the authors should be able to just do a PR to this official opcode repo with the source code / CMake file (maybe some kind of package/opcode definition file) and it should be added into the catalog automatically from there. That gives a low barrier for entry for people which should encourage adding content.

 

I think for bigger opcodes, sure we could add submodules that point to an external repo. The author would have to make a PR for us to up date this link in the main repo if they update their local opcode repo but that’s not a huge deal I suppose.

 

One thing to consider though, is there any concept of versioning with current opcodes? Should these built opcodes work with any past and future Csound version? How can a breaking API change be implemented?

 

Stephen

 

From: Michael Gogins
Sent: Tuesday 19 November 2019 23:30
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] plugins repository

 

Not a good idea at all, unless there is a continuous integration pipeline that produces release builds for all platforms.

 

Regards, 

Mine

 

On Tue, Nov 19, 2019, 08:11 Rory Walsh <rorywalsh@ear.ie> wrote:

That's a good point about platforms. Might I suggest that all opcodes pushed to this repo must build on the three major platforms? 

 

On Tue, 19 Nov 2019 at 14:57, Michael Gogins <michael.gogins@gmail.com> wrote:

Thanks. Simple and straightforward. 

 

The question about submodules is good. Moving or deleting them can be a pain.

 

I also wonder about support for multiple platforms. 

 

Regards, 

Mike

 

On Tue, Nov 19, 2019, 05:14 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

yes, for every plugin lib.

Prof. Victor Lazzarini

Maynooth University

Ireland


On 19 Nov 2019, at 12:50, Rory Walsh <rorywalsh@ear.ie> wrote:

So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?

 

On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add

add_subdirectory(...)

to it and have a simple CMakeLists.txt in the directory.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>
> Hi Mike,
>
> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>
> Regards
>
> François
>
> Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
>
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com

 


Date2019-11-20 06:48
FromVictor Lazzarini
SubjectRe: [Csnd-dev] plugins repository
I think we are close to having that.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 19 Nov 2019, at 22:30, Michael Gogins <michael.gogins@gmail.com> wrote:

Not a good idea at all, unless there is a continuous integration pipeline that produces release builds for all platforms.

Regards, 
Mine

On Tue, Nov 19, 2019, 08:11 Rory Walsh <rorywalsh@ear.ie> wrote:
That's a good point about platforms. Might I suggest that all opcodes pushed to this repo must build on the three major platforms? 

On Tue, 19 Nov 2019 at 14:57, Michael Gogins <michael.gogins@gmail.com> wrote:
Thanks. Simple and straightforward. 

The question about submodules is good. Moving or deleting them can be a pain.

I also wonder about support for multiple platforms. 

Regards, 
Mike

On Tue, Nov 19, 2019, 05:14 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
yes, for every plugin lib.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 19 Nov 2019, at 12:50, Rory Walsh <rorywalsh@ear.ie> wrote:

So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?

On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:
I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add

add_subdirectory(...)

to it and have a simple CMakeLists.txt in the directory.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>
> Hi Mike,
>
> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>
> Regards
>
> François
>
> Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
>
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com


Date2019-11-20 06:52
FromVictor Lazzarini
SubjectRe: [Csnd-dev] plugins repository
yes, there is versioning in the current plugin system. I've seen opcodes not loaded because versions did not match, but I need to check the details.

Prof. Victor Lazzarini
Maynooth University
Ireland

On 19 Nov 2019, at 23:47, Michael Gogins <michael.gogins@gmail.com> wrote:

Good question about API version compatibility. The policy has been AFAIK to leave existing calls in place and add new ones only at the end of the CSOUND struct, which should preserve backwards compatibility.

Regards, 
Mike

On Tue, Nov 19, 2019, 14:46 Stephen Kyne <stevek@outlook.ie> wrote:

There will be a CI pipeline though. I mentioned earlier, this could form the foundation of a package manager for opcodes. We should leverage Azure Pipelines to build on every platform and deploy the builds somewhere where the PM can pull them from.

 

I think for any small opcodes, the authors should be able to just do a PR to this official opcode repo with the source code / CMake file (maybe some kind of package/opcode definition file) and it should be added into the catalog automatically from there. That gives a low barrier for entry for people which should encourage adding content.

 

I think for bigger opcodes, sure we could add submodules that point to an external repo. The author would have to make a PR for us to up date this link in the main repo if they update their local opcode repo but that’s not a huge deal I suppose.

 

One thing to consider though, is there any concept of versioning with current opcodes? Should these built opcodes work with any past and future Csound version? How can a breaking API change be implemented?

 

Stephen

 

From: Michael Gogins
Sent: Tuesday 19 November 2019 23:30
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] plugins repository

 

Not a good idea at all, unless there is a continuous integration pipeline that produces release builds for all platforms.

 

Regards, 

Mine

 

On Tue, Nov 19, 2019, 08:11 Rory Walsh <rorywalsh@ear.ie> wrote:

That's a good point about platforms. Might I suggest that all opcodes pushed to this repo must build on the three major platforms? 

 

On Tue, 19 Nov 2019 at 14:57, Michael Gogins <michael.gogins@gmail.com> wrote:

Thanks. Simple and straightforward. 

 

The question about submodules is good. Moving or deleting them can be a pain.

 

I also wonder about support for multiple platforms. 

 

Regards, 

Mike

 

On Tue, Nov 19, 2019, 05:14 Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

yes, for every plugin lib.

Prof. Victor Lazzarini

Maynooth University

Ireland


On 19 Nov 2019, at 12:50, Rory Walsh <rorywalsh@ear.ie> wrote:

So should devs create a new folder for every plugin? That seems a little much. Would it be better for devs to create a submodule for themselves? And then they can just keep pushing stuff to their submodules?

 

On Tue, 19 Nov 2019 at 12:38, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

I have added a CMakeLists.txt at the top level directory in the plugins repo. Now, for new plugins we can just add

add_subdirectory(...)

to it and have a simple CMakeLists.txt in the directory.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 18 Nov 2019, at 20:21, Francois PINOT <fggpinot@gmail.com> wrote:
>
> Hi Mike,
>
> for me the head of the plugins tree is the plugins repository. It hasn't yet a CMakeLists.txt file because there's only one plugin now (py). Each new plugin should have it's own directory at the same level of the py directory, with it's own CMakeLists.txt file. One should have a CMakeLists.txt file at the root of the plugins repository allowing to pass build options and to choose which plugin(s) one wants to build.
>
> Regards
>
> François
>
> Le lun. 18 nov. 2019 à 21:01, Michael Gogins <michael.gogins@gmail.com> a écrit :
> I think having a plugins repository is a great idea. Currently, the
> Python opcodes reside at the top level of the plugins tree. Shouldn't
> each plugin have its own directory in the repository?
>
> Then a master CMakeLists.txt could simply include a subdirectory for
> each plugin's own CMakeLists.txt.
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com