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

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

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

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

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

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

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

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

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
>>>>

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

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
>>>>>

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