Hi, I'm releasing an update of ELSE but I now have a whole new build system with cmake, see https://github.com/porres/pd-else?tab=readme-ov-file#building-else-for-pd-va...
And I need help compiling it for Linux and Windows.
By the way, building for double precision Pd is now possible, and I was able to compile for macOS just fine, but more tests need to be made. I am putting this up in deken for tests.
Here's the link to the tagged release https://github.com/porres/pd-else/releases/tag/v.1.0-rc12
Please get in touch and let me know if you can help. I am looking for binaries for raspberry pi, linux and windows, both single and double precision.
thanks
Am 24. September 2024 03:03:30 MESZ schrieb Alexandre porres@gmail.com:
Hi, I'm releasing an update of ELSE but I now have a whole new build system with cmake,
[...]
And I need help compiling it for Linux and Windows.
I wonder what features you need from your build system that cannot be satisfied by pd-lib-builder. ELSE is being built for different Pd backends (vanilla, plug data,...) and I figure that was part of the motivation (and my gut feeling tries to tell me, that there's also a "'make' is from the past century, everybody uses 'cmake'" by whoever wrote the new build system, but that is mere conjecture).
In any case I would be interested in the motivation for switching a relatively simple library like ELSE.
(I can think of one good reason, but free people seem to need it)
By the way, building for double precision Pd is now possible
As a packager I found it super simple to add double precision builds to dozens of pd-lib-builder based externals without needing to touch their build system at all. So why was that complicated/impossible for ELSE?
mfg.sfg.jfd IOhannes
Em ter., 24 de set. de 2024 às 00:43, IOhannes m zmölnig zmoelnig@iem.at escreveu:
I wonder what features you need from your build system that cannot be satisfied by pd-lib-builder.
Hi, good question. I'm not sure how to answer though :) I need to get Timothy involved for that (copied here) as he was the one who promoted the change.
Honestly, I was happy with pd-lib-builder, but things got complex and the it was I was just not able to build it all at once and had to do it separately for some special objects, namely circuit~, sfz~, sfont~, pdlink/pdlink~, play.file~ and sfload (and maybe something 'else').
When asking for Tim's help to simplify the build system he was just more comfortable in using this other system instead as he was more familiar with it, so it seems.
I could go back to pdlibbuilder any time I guess, but I would need help in order to make it all more streamlined.
By the way, building for double precision Pd is now possible
As a packager I found it super simple to add double precision builds to dozens of pd-lib-builder based externals without needing to touch their build system at all. So why was that complicated/impossible for ELSE?
The change was not to make this possible, it was quite possible with pd-li-builder. What I am saying is that I finally got the code ready and made some changes so it would all compile for double precision, as I promised by the way :) though this is surely still experimental and needs testing. I will probably need to do something 'else'.
Now, my biggest issue is that I haven't had the time yet to set new virtual machines on my new arm mac to build for linux/windows
cheers
mfg.sfg.jfd IOhannes
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/DPGKSG7S3M...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
On 24.09.2024 11:59, Alexandre wrote:
Em ter., 24 de set. de 2024 às 00:43, IOhannes m zmölnig zmoelnig@iem.at escreveu:
I wonder what features you need from your build system that cannot be satisfied by pd-lib-builder.Hi, good question. I'm not sure how to answer though :) I need to get Timothy involved for that (copied here) as he was the one who promoted the change.
Honestly, I was happy with pd-lib-builder, but things got complex and the it was I was just not able to build it all at once and had to do it separately for some special objects, namely circuit~, sfz~, sfont~, pdlink/pdlink~, play.file~ and sfload (and maybe something 'else').
You can pass additional makefiles to pd-lib-builder with the "makefiles:" variable, so that shouldn't be a problem.
When asking for Tim's help to simplify the build system he was just more comfortable in using this other system instead as he was more familiar with it, so it seems.
Wait, you asked him to help with the pd-lib-builder system and he just switched everything to CMake? That's pretty hilarious :-D
I'm using CMake for my own more complex externals, so there's nothing wrong with that, but I do think that Pd externals should use pd-lib-builder whenever possible, just because it has become the de-facto standard. (Although I do think that CMake is strictly better than plain Makefiles.) So unless you have a really good technical reason for using CMake, I think you should switch back to pd-lib-builder.
I could go back to pdlibbuilder any time I guess, but I would need help in order to make it all more streamlined.
>By the way, building for double precision Pd is now possible As a packager I found it super simple to add double precision builds to dozens of pd-lib-builder based externals without needing to touch their build system at all. So why was that complicated/impossible for ELSE?The change was not to make this possible, it was quite possible with pd-li-builder. What I am saying is that I finally got the code ready and made some changes so it would all compile for double precision, as I promised by the way :) though this is surely still experimental and needs testing. I will probably need to do something 'else'.
Now, my biggest issue is that I haven't had the time yet to set new virtual machines on my new arm mac to build for linux/windows
cheers
mfg.sfg.jfd IOhannes --- pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/DPGKSG7S3MFEEO73URHQGJBI5DU3RTQ2/ To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/DXUWCDVN6G...
To unsubscribe send an email topd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.iem.at/
When asking for Tim's help to simplify the build system he was just more comfortable in using this other system instead as he was more familiar with it, so it seems.
Wait, you asked him to help with the pd-lib-builder system and he just switched everything to CMake? That's pretty hilarious :-D
No offense to Tim, he is obviously a brilliant guy. He was just a bit over-eager :)
Em ter., 24 de set. de 2024 às 11:50, Christof Ressi info@christofressi.com escreveu:
Wait, you asked him to help with the pd-lib-builder system and he just switched everything to CMake? That's pretty hilarious :-D
that's pretty much it :)
I'm using CMake for my own more complex externals, so there's nothing wrong with that, but I do think that Pd externals should use pd-lib-builder whenever possible, just because it has become the de-facto standard. (Although I do think that CMake is strictly better than plain Makefiles.) So unless you have a really good technical reason for using CMake, I think you should switch back to pd-lib-builder.
I asked Tim to reply to you people here about this.
Anyway, Tim was able to give me binaries for Linux and Windows. So I'll announce the upgrade.
I tested a double precision version here downloaded from deken on my arm mac and Pd blew up, so I guess we're not ready yet :(
Other tests from the deken download for single precision works just fine, I tested mac on intel and arm, Tim tested on Linux. Anyway, I'll make the official announcement and would like you people to also test the downloads.
And I would ask IOhanness or anyone else's help to see what objects aren't ready yet for double precision. I guess this will be really good to go only in the next upgrade! But at least it builds :)
I would still need help for raspberry pi builds as usual
cheers
Hi!
The reason for cmake is that ELSE depends on various other libraries that use cmake build systems, like sfizz, opus, and a few more. There are also a few objects that have complicated build systems, like [play.file~], [circuit~], [sfont~], [sfz~], [pdlink~], and a few more. Dealing with complicated sub-buildsystems with makefiles is not as easy as it is with cmake.
On top of that, Pierre Guillot's pd.build system for cmake is fantastic. It just generates a normal cmake target, so you can use regular cmake syntax to manipulate it. IMO, that makes it a lot easier to work with than pd-lib-builder for complex build systems.
The main goal was that you can compile the entirety of ELSE using a single build command. Before we changed to cmake, that was not working. This change also drastically simplified our CI, and allows for CI build caching.
It probably could have been done with pd-lib-builder too, but the resulting build system would have been more difficult to maintain than the cmake equivalent. And since porres mostly lets me fix the build system when things break, it made sense to use something that I'm more comfortable with. He only asked for help here because I was taking a small break, but I'm back now and have helped him finish the release.
So, lots of reasons, hope it makes sense!
Tim
On 24/09/2024 05:43, IOhannes m zmölnig wrote:
Am 24. September 2024 03:03:30 MESZ schrieb Alexandre porres@gmail.com:
Hi, I'm releasing an update of ELSE but I now have a whole new build system with cmake,
[...]
And I need help compiling it for Linux and Windows.
I wonder what features you need from your build system that cannot be satisfied by pd-lib-builder. ELSE is being built for different Pd backends (vanilla, plug data,...) and I figure that was part of the motivation (and my gut feeling tries to tell me, that there's also a "'make' is from the past century, everybody uses 'cmake'" by whoever wrote the new build system, but that is mere conjecture).
In any case I would be interested in the motivation for switching a relatively simple library like ELSE.
(I can think of one good reason, but free people seem to need it)
By the way, building for double precision Pd is now possible
As a packager I found it super simple to add double precision builds to dozens of pd-lib-builder based externals without needing to touch their build system at all. So why was that complicated/impossible for ELSE?
mfg.sfg.jfd IOhannes
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/DPGKSG7S3M...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
On 24.09.2024 18:42, Timothy Schoen wrote:
Hi!
The reason for cmake is that ELSE depends on various other libraries that use cmake build systems, like sfizz, opus, and a few more. There are also a few objects that have complicated build systems, like [play.file~], [circuit~], [sfont~], [sfz~], [pdlink~], and a few more. Dealing with complicated sub-buildsystems with makefiles is not as easy as it is with cmake.
Totally makes sense! pd-lib-builder is cool for simple externals, but it breaks down for more complex projects. I use CMake myself for some of my externals for various reasons.
That being said, I'd argue that most of the subprojects in [else] should really be dedicated externals, but somehow Alex seems to be a fan of huge monorepos :)
Christof
On top of that, Pierre Guillot's pd.build system for cmake is fantastic. It just generates a normal cmake target, so you can use regular cmake syntax to manipulate it. IMO, that makes it a lot easier to work with than pd-lib-builder for complex build systems.
The main goal was that you can compile the entirety of ELSE using a single build command. Before we changed to cmake, that was not working. This change also drastically simplified our CI, and allows for CI build caching.
It probably could have been done with pd-lib-builder too, but the resulting build system would have been more difficult to maintain than the cmake equivalent. And since porres mostly lets me fix the build system when things break, it made sense to use something that I'm more comfortable with. He only asked for help here because I was taking a small break, but I'm back now and have helped him finish the release.
So, lots of reasons, hope it makes sense!
Tim
On 24/09/2024 05:43, IOhannes m zmölnig wrote:
Am 24. September 2024 03:03:30 MESZ schrieb Alexandre porres@gmail.com:
Hi, I'm releasing an update of ELSE but I now have a whole new build system with cmake,
[...]
And I need help compiling it for Linux and Windows.
I wonder what features you need from your build system that cannot be satisfied by pd-lib-builder. ELSE is being built for different Pd backends (vanilla, plug data,...) and I figure that was part of the motivation (and my gut feeling tries to tell me, that there's also a "'make' is from the past century, everybody uses 'cmake'" by whoever wrote the new build system, but that is mere conjecture).
In any case I would be interested in the motivation for switching a relatively simple library like ELSE.
(I can think of one good reason, but free people seem to need it)
By the way, building for double precision Pd is now possible
As a packager I found it super simple to add double precision builds to dozens of pd-lib-builder based externals without needing to touch their build system at all. So why was that complicated/impossible for ELSE?
mfg.sfg.jfd IOhannes
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/DPGKSG7S3M...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/HEWMJ4VWLZ...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Em ter., 24 de set. de 2024 às 14:09, Christof Ressi info@christofressi.com escreveu:
That being said, I'd argue that most of the subprojects in [else] should really be dedicated externals, but somehow Alex seems to be a fan of huge monorepos :)
I can take the blame... guilty as charged ;)
But I'd like to share it with Tim :) who also likes the idea that ELSE is the monolith that mostly backs PlugData, and that you only need to install it (and Cyclone) to offer a full compatibility between PlugData and Pd-Vanilla.
While we're at it, I think ELSE relates a lot to ceammc, which is also a monolithic distribution, but also a fork of Pd. I wouldn't go as far as forking Pd, but in a sense, having Pd-Vanilla with ELSE is a bit like running a fork of Pd, with even GUI plugins.
And I like this idea of offering a cohesive and complete system, and that it is also the single dependency of my Live Electronics Tutorial. In fact, the Live Electronics Tutorial is the true thing that did motivate it all... ELSE was just something to back it up...
But now that we have PlugData I also see ELSE as the backbone of this fork.
cheers
-
Alexandre -
Christof Ressi -
IOhannes m zmölnig -
Timothy Schoen