It's an easy fix.
I originally thought creating the app bundle with the full source tree files and the compilation step .o files was a bug and not a feature. The resulting .app is thus smaller. The app bundler script was written before the pd con and I didn't recognize the feature when presented.
I'd say that if Pd is easier to build, we don't need this but I'm probably wrong. At the very least, the header directory can be named back to "src"
On Aug 15, 2017, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
Dan was unaware of this when reorganizing the build scripts for the bundle, and while I'm writing this he opened an issue suggesting a fix: https://github.com/pure-data/pure-data/issues/181 https://github.com/pure-data/pure-data/issues/181
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Does the new build script automatically create a complete and deterministic source distribution for the app bundle? Or do you still need to add and configure things 'by hand'? One conclusion from PdCon sessions about building Pd was, a source repository snapshot is not necessarily the same as a source distribution. Pd for OSX used to be a combined source / binary distribution. If the build is hard(er) to reproduce without embedded sources, I guess they should better be included like before. When this is the preferred approach for deken packages, why not for Pd.
Katja
On Tue, Aug 15, 2017 at 12:05 PM, Dan Wilcox danomatika@gmail.com wrote:
It's an easy fix.
I originally thought creating the app bundle with the full source tree files and the compilation step .o files was a bug and not a feature. The resulting .app is thus smaller. The app bundler script was written before the pd con and I didn't recognize the feature when presented.
I'd say that if Pd is easier to build, we don't need this but I'm probably wrong. At the very least, the header directory can be named back to "src"
On Aug 15, 2017, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
Dan was unaware of this when reorganizing the build scripts for the bundle, and while I'm writing this he opened an issue suggesting a fix: https://github.com/pure-data/pure-data/issues/181
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Aug 15, 2017, at 1:42 PM, katja katjavetter@gmail.com wrote:
Does the new build script automatically create a complete and deterministic source distribution for the app bundle?
No. It copies only the binaries and required resource files for the app to run. It does include the source files or the built .o files.
It would be easy to have it copy in the .c and .h files if desired, see the script itself: https://github.com/pure-data/pure-data/blob/master/mac/osx-app.sh https://github.com/pure-data/pure-data/blob/master/mac/osx-app.sh
Or do you still need to add and configure things 'by hand'?
No. The idea is that we don't have to do anything by hand, partially because it's my opinion that if Pd is easier to build we can empower users. Being able to easily build a configurable .app with different versions of Tk was also a requirement for testing/supporting non-ancient versions of macOS. At the time I started with this work, you couldn't even build Pd on anything newer than 10.9. The vast majority of macOS users are on the latest two releases.
This setup is fully documented: https://github.com/pure-data/pure-data/tree/master/mac https://github.com/pure-data/pure-data/tree/master/mac
One conclusion from PdCon sessions about building Pd was, a source repository snapshot is not necessarily the same as a source distribution. Pd for OSX used to be a combined source / binary distribution. If the build is hard(er) to reproduce without embedded sources, I guess they should better be included like before. When this is the preferred approach for deken packages, why not for Pd.
The script is easy to change and it's not a big deal to handle either requirement.
It's my opinion that users should be both able to and encouraged to build from source if they want to and my efficiency side doesn't see the need for the .o files. In that regard, I don't see the reason to distribute the partial build artifacts and I'm not sure if I could link a .o built on 10.6 on 10.12 but I haven't quite figured out the details on being able to build binaries which work better across the versions. So far, building on an older machine gives binaries which run ok on most newer versions, but not the other way around (at least with the GUI). That's one advantage I can see for including all the artifacts. This needs some more testing to know the full situation.
However, my change when writing the script was not meant as final decision in any way. As always, I put the work forward for review and feedback and did not receive any feedback on this aspects of things, even though I had put out custom app builds. In any case, I can do whatever is needed via consensus.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Scratch part of the last email. I think I'm confusing things.
The old script build the app bundle and simply copied in the entire folder contents, including build artifacts.
The new script builds the app bundle and copies in only specified things.
By "source distribution" I'm guessing you mean the actual source files, makefiles etc and not the pre-build artifacts?
One thing to note: IOhannes and I removed the generated autotools files (configure, m4 stuff, Makefile, Makefile.in) so the source tarball should behave without having to change anything by hand. The configure script was *greatly* updated to facilitate this as well. It should work whether inside the .app or not.
I guess what I don't understand is the need for both a source tarball and a .app which includes all the sources. It should be possible now to build Pd on Mac 10.6 to 10.12 (and soon 10.13) with the same steps.
On Aug 15, 2017, at 2:06 PM, Dan Wilcox danomatika@gmail.com wrote:
On Aug 15, 2017, at 1:42 PM, katja <katjavetter@gmail.com mailto:katjavetter@gmail.com> wrote:
Does the new build script automatically create a complete and deterministic source distribution for the app bundle?
No. It copies only the binaries and required resource files for the app to run. It does include the source files or the built .o files.
It would be easy to have it copy in the .c and .h files if desired, see the script itself: https://github.com/pure-data/pure-data/blob/master/mac/osx-app.sh https://github.com/pure-data/pure-data/blob/master/mac/osx-app.sh
Or do you still need to add and configure things 'by hand'?
No. The idea is that we don't have to do anything by hand, partially because it's my opinion that if Pd is easier to build we can empower users. Being able to easily build a configurable .app with different versions of Tk was also a requirement for testing/supporting non-ancient versions of macOS. At the time I started with this work, you couldn't even build Pd on anything newer than 10.9. The vast majority of macOS users are on the latest two releases.
This setup is fully documented: https://github.com/pure-data/pure-data/tree/master/mac https://github.com/pure-data/pure-data/tree/master/mac
One conclusion from PdCon sessions about building Pd was, a source repository snapshot is not necessarily the same as a source distribution. Pd for OSX used to be a combined source / binary distribution. If the build is hard(er) to reproduce without embedded sources, I guess they should better be included like before. When this is the preferred approach for deken packages, why not for Pd.
The script is easy to change and it's not a big deal to handle either requirement.
It's my opinion that users should be both able to and encouraged to build from source if they want to and my efficiency side doesn't see the need for the .o files. In that regard, I don't see the reason to distribute the partial build artifacts and I'm not sure if I could link a .o built on 10.6 on 10.12 but I haven't quite figured out the details on being able to build binaries which work better across the versions. So far, building on an older machine gives binaries which run ok on most newer versions, but not the other way around (at least with the GUI). That's one advantage I can see for including all the artifacts. This needs some more testing to know the full situation.
However, my change when writing the script was not meant as final decision in any way. As always, I put the work forward for review and feedback and did not receive any feedback on this aspects of things, even though I had put out custom app builds. In any case, I can do whatever is needed via consensus.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Also, the steps are outlined in the greatly updated INSTALL.txt: https://github.com/pure-data/pure-data/blob/master/INSTALL.txt https://github.com/pure-data/pure-data/blob/master/INSTALL.txt
On Aug 15, 2017, at 2:15 PM, Dan Wilcox danomatika@gmail.com wrote:
One thing to note: IOhannes and I removed the generated autotools files (configure, m4 stuff, Makefile, Makefile.in) so the source tarball should behave without having to change anything by hand. The configure script was *greatly* updated to facilitate this as well. It should work whether inside the .app or not.
I guess what I don't understand is the need for both a source tarball and a .app which includes all the sources. It should be possible now to build Pd on Mac 10.6 to 10.12 (and soon 10.13) with the same steps.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
And to clarify, this "I guess what I don't understand is the need for both a source tarball and a .app which includes all the sources." does not mean I am against making any changes and am against source distributions. It's only a question really as I've not needed that kind of feature, personally.
On Aug 15, 2017, at 2:18 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, the steps are outlined in the greatly updated INSTALL.txt: https://github.com/pure-data/pure-data/blob/master/INSTALL.txt https://github.com/pure-data/pure-data/blob/master/INSTALL.txt
On Aug 15, 2017, at 2:15 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
One thing to note: IOhannes and I removed the generated autotools files (configure, m4 stuff, Makefile, Makefile.in) so the source tarball should behave without having to change anything by hand. The configure script was *greatly* updated to facilitate this as well. It should work whether inside the .app or not.
I guess what I don't understand is the need for both a source tarball and a .app which includes all the sources. It should be possible now to build Pd on Mac 10.6 to 10.12 (and soon 10.13) with the same steps.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan, the new documentations are great!
Is it the case that Miller switched from 'old build system' (makefile.mac etc.) to autotools between 0.47-* and 0.48-*? That would explain why a simple rebuild within the app bundle was feasible at the time of PdCon16~, while it is not even technically possible currently. The makefile.mac is a source file, while makefile(s) from an autotools build system are not, so no way to 'cd to the source directory and hit make' as it was phrased in the PdCon presentation.
I'm slowly starting to understand that the lost option to rebuild within the app bundle is a logical consequence of switching from one build method to the other. And including the complete source files is of no use then. So I rest my case!
By the way I wonder if the same is going on with the Windows package?
Katja
On Tue, Aug 15, 2017 at 2:44 PM, Dan Wilcox danomatika@gmail.com wrote:
And to clarify, this "I guess what I don't understand is the need for both a source tarball and a .app which includes all the sources." does not mean I am against making any changes and am against source distributions. It's only a question really as I've not needed that kind of feature, personally.
On Aug 15, 2017, at 2:18 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, the steps are outlined in the greatly updated INSTALL.txt: https://github.com/pure-data/pure-data/blob/master/INSTALL.txt
On Aug 15, 2017, at 2:15 PM, Dan Wilcox danomatika@gmail.com wrote:
One thing to note: IOhannes and I removed the generated autotools files (configure, m4 stuff, Makefile, Makefile.in) so the source tarball should behave without having to change anything by hand. The configure script was *greatly* updated to facilitate this as well. It should work whether inside the .app or not.
I guess what I don't understand is the need for both a source tarball and a .app which includes all the sources. It should be possible now to build Pd on Mac 10.6 to 10.12 (and soon 10.13) with the same steps.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
As far as I know, the release builds still use Miller's makefiles. The mac build just now uses the mac/osx-app.sh script to generate the .app. I checked the windows download and it includes everything as before.
On Aug 16, 2017, at 10:52 AM, katja katjavetter@gmail.com wrote:
Dan, the new documentations are great!
Is it the case that Miller switched from 'old build system' (makefile.mac etc.) to autotools between 0.47-* and 0.48-*? That would explain why a simple rebuild within the app bundle was feasible at the time of PdCon16~, while it is not even technically possible currently. The makefile.mac is a source file, while makefile(s) from an autotools build system are not, so no way to 'cd to the source directory and hit make' as it was phrased in the PdCon presentation.
I'm slowly starting to understand that the lost option to rebuild within the app bundle is a logical consequence of switching from one build method to the other. And including the complete source files is of no use then. So I rest my case!
By the way I wonder if the same is going on with the Windows package?
Katja
On Tue, Aug 15, 2017 at 2:44 PM, Dan Wilcox danomatika@gmail.com wrote:
And to clarify, this "I guess what I don't understand is the need for both a source tarball and a .app which includes all the sources." does not mean I am against making any changes and am against source distributions. It's only a question really as I've not needed that kind of feature, personally.
On Aug 15, 2017, at 2:18 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, the steps are outlined in the greatly updated INSTALL.txt: https://github.com/pure-data/pure-data/blob/master/INSTALL.txt
On Aug 15, 2017, at 2:15 PM, Dan Wilcox danomatika@gmail.com wrote:
One thing to note: IOhannes and I removed the generated autotools files (configure, m4 stuff, Makefile, Makefile.in) so the source tarball should behave without having to change anything by hand. The configure script was *greatly* updated to facilitate this as well. It should work whether inside the .app or not.
I guess what I don't understand is the need for both a source tarball and a .app which includes all the sources. It should be possible now to build Pd on Mac 10.6 to 10.12 (and soon 10.13) with the same steps.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
It's ugly :)
I'm using Dan's autotools setup to build the i386 and ia64 MacOS versions, and my own ad hoc system (makefile.mac) to build for PPC.
I was sorry to see the capability to recompile-within-the-app disappear but I think the way the autotools build system works makes this much more awkward (you have to run 'make install' to get the file tree in a state where Pd can find its support files).
My original intent in supplying the source files as part of the distro was also to provide an archival trace for anyone wanting to run a Pd application (such as a piece of music) far in the future, when it might be hard to find sources for a particular version of Pd. I still really like the idea of being able to easily make a fully-documented realization of a piece of music by supplying patches and a version of Pd (and all non-vanilla extensions used) in a single file tree.
For windows, I'm still using my old scripts, not autotools, but I want to re-think that for the next version, particularly in order to be able to make a 64-bit version for windows. I'm agonizing over what t_float size to use - I could make it 64 by default (and later once I've figured out how to manage it, start offering 64-bit-float for linux and Mac too :)
Miller
On Wed, Aug 16, 2017 at 11:10:35AM +0200, Dan Wilcox wrote:
As far as I know, the release builds still use Miller's makefiles. The mac build just now uses the mac/osx-app.sh script to generate the .app. I checked the windows download and it includes everything as before.
On Aug 16, 2017, at 10:52 AM, katja katjavetter@gmail.com wrote:
Dan, the new documentations are great!
Is it the case that Miller switched from 'old build system' (makefile.mac etc.) to autotools between 0.47-* and 0.48-*? That would explain why a simple rebuild within the app bundle was feasible at the time of PdCon16~, while it is not even technically possible currently. The makefile.mac is a source file, while makefile(s) from an autotools build system are not, so no way to 'cd to the source directory and hit make' as it was phrased in the PdCon presentation.
I'm slowly starting to understand that the lost option to rebuild within the app bundle is a logical consequence of switching from one build method to the other. And including the complete source files is of no use then. So I rest my case!
By the way I wonder if the same is going on with the Windows package?
Katja
On Tue, Aug 15, 2017 at 2:44 PM, Dan Wilcox danomatika@gmail.com wrote:
And to clarify, this "I guess what I don't understand is the need for both a source tarball and a .app which includes all the sources." does not mean I am against making any changes and am against source distributions. It's only a question really as I've not needed that kind of feature, personally.
On Aug 15, 2017, at 2:18 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, the steps are outlined in the greatly updated INSTALL.txt: https://github.com/pure-data/pure-data/blob/master/INSTALL.txt
On Aug 15, 2017, at 2:15 PM, Dan Wilcox danomatika@gmail.com wrote:
One thing to note: IOhannes and I removed the generated autotools files (configure, m4 stuff, Makefile, Makefile.in) so the source tarball should behave without having to change anything by hand. The configure script was *greatly* updated to facilitate this as well. It should work whether inside the .app or not.
I guess what I don't understand is the need for both a source tarball and a .app which includes all the sources. It should be possible now to build Pd on Mac 10.6 to 10.12 (and soon 10.13) with the same steps.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Aug 16, 2017, at 6:16 PM, Miller Puckette msp@ucsd.edu wrote:
It's ugly :)
I'm using Dan's autotools setup to build the i386 and ia64 MacOS versions, and my own ad hoc system (makefile.mac) to build for PPC.
You should be able to build a combined i386, x86_64, and ppc binary using the auto tools setup when using the --enable-universal on a system with the 10.6 SDK:
./configure --enable-universal
At least we have that capability in place, but I've not had an old machine to be able to fully test it.
I was sorry to see the capability to recompile-within-the-app disappear but I think the way the autotools build system works makes this much more awkward (you have to run 'make install' to get the file tree in a state where Pd can find its support files).
It should still be possible if copying in the symbolic links to the binaries in the bin folder and leave the actual binaries in the src folder. That was my thinking with adding a new flag to the sox-app.sh script to either create a "fat" or "slim" app.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Wed, Aug 16, 2017 at 08:03:47PM +0200, Dan Wilcox wrote:
On Aug 16, 2017, at 6:16 PM, Miller Puckette msp@ucsd.edu wrote:
It's ugly :)
I'm using Dan's autotools setup to build the i386 and ia64 MacOS versions, and my own ad hoc system (makefile.mac) to build for PPC.
You should be able to build a combined i386, x86_64, and ppc binary using the auto tools setup when using the --enable-universal on a system with the 10.6 SDK:
./configure --enable-universalAt least we have that capability in place, but I've not had an old machine to be able to fully test it.
cool, I'll give that a try. I think there still have to be 2 targets so that one can run i386 Pd on 64-bit machines. So I don't feel an urgent need to get this working rigth away.
I was sorry to see the capability to recompile-within-the-app disappear but I think the way the autotools build system works makes this much more awkward (you have to run 'make install' to get the file tree in a state where Pd can find its support files).
It should still be possible if copying in the symbolic links to the binaries in the bin folder and leave the actual binaries in the src folder. That was my thinking with adding a new flag to the sox-app.sh script to either create a "fat" or "slim" app.
or better yet I can fix the source to be able to withstand the alternative layout. That will be needed when getting this all running on WIndows which as far as I know has never supported symlinks.
cheers Miller
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Windows, I think the binaries are simply copied into bin.
In any case, one of my upcoming goals is to get the auto tools windows build working.
On Aug 16, 2017, at 8:15 PM, Miller Puckette msp@ucsd.edu wrote:
or better yet I can fix the source to be able to withstand the alternative layout. That will be needed when getting this all running on WIndows which as far as I know has never supported symlinks.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Hi, since Pd 0.48-1 will be released soon I wonder if there will be a source dir in the Windows and OSX distributions?
Katja
On Wed, Aug 16, 2017 at 6:16 PM, Miller Puckette msp@ucsd.edu wrote:
It's ugly :)
I'm using Dan's autotools setup to build the i386 and ia64 MacOS versions, and my own ad hoc system (makefile.mac) to build for PPC.
I was sorry to see the capability to recompile-within-the-app disappear but I think the way the autotools build system works makes this much more awkward (you have to run 'make install' to get the file tree in a state where Pd can find its support files).
My original intent in supplying the source files as part of the distro was also to provide an archival trace for anyone wanting to run a Pd application (such as a piece of music) far in the future, when it might be hard to find sources for a particular version of Pd. I still really like the idea of being able to easily make a fully-documented realization of a piece of music by supplying patches and a version of Pd (and all non-vanilla extensions used) in a single file tree.
For windows, I'm still using my old scripts, not autotools, but I want to re-think that for the next version, particularly in order to be able to make a 64-bit version for windows. I'm agonizing over what t_float size to use - I could make it 64 by default (and later once I've figured out how to manage it, start offering 64-bit-float for linux and Mac too :)
Miller
On Wed, Aug 16, 2017 at 11:10:35AM +0200, Dan Wilcox wrote:
As far as I know, the release builds still use Miller's makefiles. The mac build just now uses the mac/osx-app.sh script to generate the .app. I checked the windows download and it includes everything as before.
On Aug 16, 2017, at 10:52 AM, katja katjavetter@gmail.com wrote:
Dan, the new documentations are great!
Is it the case that Miller switched from 'old build system' (makefile.mac etc.) to autotools between 0.47-* and 0.48-*? That would explain why a simple rebuild within the app bundle was feasible at the time of PdCon16~, while it is not even technically possible currently. The makefile.mac is a source file, while makefile(s) from an autotools build system are not, so no way to 'cd to the source directory and hit make' as it was phrased in the PdCon presentation.
I'm slowly starting to understand that the lost option to rebuild within the app bundle is a logical consequence of switching from one build method to the other. And including the complete source files is of no use then. So I rest my case!
By the way I wonder if the same is going on with the Windows package?
Katja
On Tue, Aug 15, 2017 at 2:44 PM, Dan Wilcox danomatika@gmail.com wrote:
And to clarify, this "I guess what I don't understand is the need for both a source tarball and a .app which includes all the sources." does not mean I am against making any changes and am against source distributions. It's only a question really as I've not needed that kind of feature, personally.
On Aug 15, 2017, at 2:18 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, the steps are outlined in the greatly updated INSTALL.txt: https://github.com/pure-data/pure-data/blob/master/INSTALL.txt
On Aug 15, 2017, at 2:15 PM, Dan Wilcox danomatika@gmail.com wrote:
One thing to note: IOhannes and I removed the generated autotools files (configure, m4 stuff, Makefile, Makefile.in) so the source tarball should behave without having to change anything by hand. The configure script was *greatly* updated to facilitate this as well. It should work whether inside the .app or not.
I guess what I don't understand is the need for both a source tarball and a .app which includes all the sources. It should be possible now to build Pd on Mac 10.6 to 10.12 (and soon 10.13) with the same steps.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I'd like to distribute sources. I believe they're included in the Windows releases but not in the Mac ones. Also, if we move to an autotools Windows build (which I think we'll have to in order to accomodate 64-bit Windows builds) the sources won't be included.
One possibility would be to include the source distribution tarball in the distributed Mac and Windows versions. You'd no longer just be able to change something and hit 'make' - instead you'd have to download the whole autotools horrorshow and do it the "official" way. I don't like that idea much but perhaps it's better than nothing. At any rate, at least for the sake of archival completeness it would be better that way.
cheers Miller
On Sat, Dec 02, 2017 at 09:54:29PM +0100, katja wrote:
Hi, since Pd 0.48-1 will be released soon I wonder if there will be a source dir in the Windows and OSX distributions?
Katja
On Wed, Aug 16, 2017 at 6:16 PM, Miller Puckette msp@ucsd.edu wrote:
It's ugly :)
I'm using Dan's autotools setup to build the i386 and ia64 MacOS versions, and my own ad hoc system (makefile.mac) to build for PPC.
I was sorry to see the capability to recompile-within-the-app disappear but I think the way the autotools build system works makes this much more awkward (you have to run 'make install' to get the file tree in a state where Pd can find its support files).
My original intent in supplying the source files as part of the distro was also to provide an archival trace for anyone wanting to run a Pd application (such as a piece of music) far in the future, when it might be hard to find sources for a particular version of Pd. I still really like the idea of being able to easily make a fully-documented realization of a piece of music by supplying patches and a version of Pd (and all non-vanilla extensions used) in a single file tree.
For windows, I'm still using my old scripts, not autotools, but I want to re-think that for the next version, particularly in order to be able to make a 64-bit version for windows. I'm agonizing over what t_float size to use - I could make it 64 by default (and later once I've figured out how to manage it, start offering 64-bit-float for linux and Mac too :)
Miller
On Wed, Aug 16, 2017 at 11:10:35AM +0200, Dan Wilcox wrote:
As far as I know, the release builds still use Miller's makefiles. The mac build just now uses the mac/osx-app.sh script to generate the .app. I checked the windows download and it includes everything as before.
On Aug 16, 2017, at 10:52 AM, katja katjavetter@gmail.com wrote:
Dan, the new documentations are great!
Is it the case that Miller switched from 'old build system' (makefile.mac etc.) to autotools between 0.47-* and 0.48-*? That would explain why a simple rebuild within the app bundle was feasible at the time of PdCon16~, while it is not even technically possible currently. The makefile.mac is a source file, while makefile(s) from an autotools build system are not, so no way to 'cd to the source directory and hit make' as it was phrased in the PdCon presentation.
I'm slowly starting to understand that the lost option to rebuild within the app bundle is a logical consequence of switching from one build method to the other. And including the complete source files is of no use then. So I rest my case!
By the way I wonder if the same is going on with the Windows package?
Katja
On Tue, Aug 15, 2017 at 2:44 PM, Dan Wilcox danomatika@gmail.com wrote:
And to clarify, this "I guess what I don't understand is the need for both a source tarball and a .app which includes all the sources." does not mean I am against making any changes and am against source distributions. It's only a question really as I've not needed that kind of feature, personally.
On Aug 15, 2017, at 2:18 PM, Dan Wilcox danomatika@gmail.com wrote:
Also, the steps are outlined in the greatly updated INSTALL.txt: https://github.com/pure-data/pure-data/blob/master/INSTALL.txt
On Aug 15, 2017, at 2:15 PM, Dan Wilcox danomatika@gmail.com wrote:
One thing to note: IOhannes and I removed the generated autotools files (configure, m4 stuff, Makefile, Makefile.in) so the source tarball should behave without having to change anything by hand. The configure script was *greatly* updated to facilitate this as well. It should work whether inside the .app or not.
I guess what I don't understand is the need for both a source tarball and a .app which includes all the sources. It should be possible now to build Pd on Mac 10.6 to 10.12 (and soon 10.13) with the same steps.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Despite popular opinion, an auto tools source release has already created the configure script so users do *not* need to run the autotools themselves, just ./configure && make.
One difference is that the mac and windows releases rely on a slightly different folder structure than that of the expected auto tools install (ie. Unix-style layout). In this case, one option is to leave everything in a source directory as suggested and then have a separate installer script which puts things into the right place. IMO it's easier to let configure/make do their jobs and extra stuff like this is better handled by installing into a temp directory and/or using a script to put things "in the right place".
It's totally possible and probably the next step after the Windows build is ironed out. (We are working on it: https://github.com/pure-data/pure-data/issues/25#issuecomment-348724495 https://github.com/pure-data/pure-data/issues/25#issuecomment-348724495)
On Dec 3, 2017, at 12:08 AM, Miller Puckette msp@ucsd.edu wrote:
You'd no longer just be able to change something and hit 'make' - instead you'd have to download the whole autotools horrorshow and do it the "official" way.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I think that means that I would have to switch from my bare source release style to releasing an autotools-source-release. And then anyhow throwing the autotools-source-release into the compiled releases.
cheers M
On Sun, Dec 03, 2017 at 12:15:37AM +0100, Dan Wilcox wrote:
Despite popular opinion, an auto tools source release has already created the configure script so users do *not* need to run the autotools themselves, just ./configure && make.
One difference is that the mac and windows releases rely on a slightly different folder structure than that of the expected auto tools install (ie. Unix-style layout). In this case, one option is to leave everything in a source directory as suggested and then have a separate installer script which puts things into the right place. IMO it's easier to let configure/make do their jobs and extra stuff like this is better handled by installing into a temp directory and/or using a script to put things "in the right place".
It's totally possible and probably the next step after the Windows build is ironed out. (We are working on it: https://github.com/pure-data/pure-data/issues/25#issuecomment-348724495 https://github.com/pure-data/pure-data/issues/25#issuecomment-348724495)
On Dec 3, 2017, at 12:08 AM, Miller Puckette msp@ucsd.edu wrote:
You'd no longer just be able to change something and hit 'make' - instead you'd have to download the whole autotools horrorshow and do it the "official" way.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Well, it's possible, but I'm not sure yet what the best way to do this might be. It's probably worth looking at other projects that do this. Perhaps IOhannes has some ideas working with Debian, etc. I'm less familiar with this approach as I'm used to downloading and building the source-only tarballs for other projects.
Like a lot of things, there might be support for this style distribution in autoconf/automake and we just need to use it (hopefully). I'd say this might be more of a 0.49 goal.
On Dec 3, 2017, at 12:20 AM, Miller Puckette msp@ucsd.edu wrote:
I think that means that I would have to switch from my bare source release style to releasing an autotools-source-release. And then anyhow throwing the autotools-source-release into the compiled releases.
cheers M
On Sun, Dec 03, 2017 at 12:15:37AM +0100, Dan Wilcox wrote:
Despite popular opinion, an auto tools source release has already created the configure script so users do *not* need to run the autotools themselves, just ./configure && make.
One difference is that the mac and windows releases rely on a slightly different folder structure than that of the expected auto tools install (ie. Unix-style layout). In this case, one option is to leave everything in a source directory as suggested and then have a separate installer script which puts things into the right place. IMO it's easier to let configure/make do their jobs and extra stuff like this is better handled by installing into a temp directory and/or using a script to put things "in the right place".
It's totally possible and probably the next step after the Windows build is ironed out. (We are working on it: https://github.com/pure-data/pure-data/issues/25#issuecomment-348724495 https://github.com/pure-data/pure-data/issues/25#issuecomment-348724495)
On Dec 3, 2017, at 12:08 AM, Miller Puckette msp@ucsd.edu wrote:
You'd no longer just be able to change something and hit 'make' - instead you'd have to download the whole autotools horrorshow and do it the "official" way.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On a platform where building Pd with autotools is just a matter of hitting ./configure && make, the need for a 'self-replicating' binary package seems to be obviated indeed. Frankly I didn't know it is so easy, since INSTALL.txt for 0.48-0 still tells you to generate the configure script. Will 0.48-1 be different in this respect?
There's another reason too I was bumping this topic: the changed API path breaks build scripts of external libraries that have the path hard-coded. Issues about this are still pending:
https://github.com/pure-data/pure-data/issues/181
https://github.com/pure-data/pd-lib-builder/issues/33
If the intention is to leave out sources from future binary distributions for all platforms, would it be an idea to include a copy of the API files in the old path (src) during a transition period, say until the next major version?
Katja
On Sun, Dec 3, 2017 at 12:24 AM, Dan Wilcox danomatika@gmail.com wrote:
Well, it's possible, but I'm not sure yet what the best way to do this might be. It's probably worth looking at other projects that do this. Perhaps IOhannes has some ideas working with Debian, etc. I'm less familiar with this approach as I'm used to downloading and building the source-only tarballs for other projects.
Like a lot of things, there might be support for this style distribution in autoconf/automake and we just need to use it (hopefully). I'd say this might be more of a 0.49 goal.
On Dec 3, 2017, at 12:20 AM, Miller Puckette msp@ucsd.edu wrote:
I think that means that I would have to switch from my bare source release style to releasing an autotools-source-release. And then anyhow throwing the autotools-source-release into the compiled releases.
cheers M
On Sun, Dec 03, 2017 at 12:15:37AM +0100, Dan Wilcox wrote:
Despite popular opinion, an auto tools source release has already created the configure script so users do *not* need to run the autotools themselves, just ./configure && make.
One difference is that the mac and windows releases rely on a slightly different folder structure than that of the expected auto tools install (ie. Unix-style layout). In this case, one option is to leave everything in a source directory as suggested and then have a separate installer script which puts things into the right place. IMO it's easier to let configure/make do their jobs and extra stuff like this is better handled by installing into a temp directory and/or using a script to put things "in the right place".
It's totally possible and probably the next step after the Windows build is ironed out. (We are working on it: https://github.com/pure-data/pure-data/issues/25#issuecomment-348724495 https://github.com/pure-data/pure-data/issues/25#issuecomment-348724495)
On Dec 3, 2017, at 12:08 AM, Miller Puckette msp@ucsd.edu wrote:
You'd no longer just be able to change something and hit 'make' - instead you'd have to download the whole autotools horrorshow and do it the "official" way.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Dec 3, 2017, at 11:46 AM, katja katjavetter@gmail.com wrote:
On a platform where building Pd with autotools is just a matter of hitting ./configure && make, the need for a 'self-replicating' binary package seems to be obviated indeed. Frankly I didn't know it is so easy, since INSTALL.txt for 0.48-0 still tells you to generate the configure script. Will 0.48-1 be different in this respect?
Short form: I an be that easy, but the current pd source tarball does not included the generated configure script.
Long form:
It *should* be that easy but it requires the source release to include the generated configure script. This can be done on a developer machine using "make dist" which generates a distribution tarball (even with the version naming), ready to go. If configure and it's m4 stuff are included, then all the user needs is a shell and compiler chain to build the project. That's part of the whole point of autotools.
The reason I added the info about installing autoconf, etc was the currently pd's source tarball is a git archive (I believe) and not an autotools dist tarball, hence the extra steps to generate configure as it's not included. We removed the generated files from the git repo as they really don't nee to be there as they can be generated like the automaker-generated makefiles.
(Throwing this link around again.) I've found this guide to be a *great* overview of how and autotools project works: https://autotools.io/whosafraid.html https://autotools.io/whosafraid.html
If the intention is to leave out sources from future binary distributions for all platforms, would it be an idea to include a copy of the API files in the old path (src) during a transition period, say until the next major version?
Right. If the requirement is that the headers need to be in a "src" folder instead of "include", I can fix that no problem as it was just a cleanup detail I've not gotten around to fixing.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Dec 3, 2017, at 1:04 PM, Dan Wilcox danomatika@gmail.com wrote:
On Dec 3, 2017, at 11:46 AM, katja <katjavetter@gmail.com mailto:katjavetter@gmail.com> wrote:
On a platform where building Pd with autotools is just a matter of hitting ./configure && make, the need for a 'self-replicating' binary package seems to be obviated indeed. Frankly I didn't know it is so easy, since INSTALL.txt for 0.48-0 still tells you to generate the configure script. Will 0.48-1 be different in this respect?
Short form: I an be that easy, but the current pd source tarball does not included the generated configure script.
Long form:
It *should* be that easy but it requires the source release to include the generated configure script. This can be done on a developer machine using "make dist" which generates a distribution tarball (even with the version naming), ready to go. If configure and it's m4 stuff are included, then all the user needs is a shell and compiler chain to build the project. That's part of the whole point of autotools.
As a followup, here is a source tarball generated from "make dist": pd-0.48.0.tar.gz http://docs.danomatika.com/pdbuilds/pd-0.48.0.tar.gz It should work on Linux and macOS. We still have some things to iron out for Windows/MinGW.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Sun, Dec 3, 2017 at 1:14 PM, Dan Wilcox danomatika@gmail.com wrote:
As a followup, here is a source tarball generated from "make dist": pd-0.48.0.tar.gz It should work on Linux and macOS. We still have some things to iron out for Windows/MinGW.
Wonderful. This is professional and user-friendly at the same time. What I understand from autotools, bootstrapping is only needed for developer tasks (like changing dependencies) and a source distribution for end users should ideally include the configure script. I was never aware that target 'dist' includes the configure script. The package in your tarball builds smooth with './configure' and 'make' (on my linux box preconfigured to build pd). With target 'dist', a new source tarball pops up in the tree. Cool!
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Sun, Dec 3, 2017 at 1:04 PM, Dan Wilcox danomatika@gmail.com wrote:
If the intention is to leave out sources from future binary distributions for all platforms, would it be an idea to include a copy of the API files in the old path (src) during a transition period, say until the next major version?
Right. If the requirement is that the headers need to be in a "src" folder instead of "include", I can fix that no problem as it was just a cleanup detail I've not gotten around to fixing.
Sorry, my phrasing wasn't completely unambiguous but I meant to say 'a copy of the API files in the old path, in addition to the API files in the new path.' For API files alone, 'include' is the conventional directory indeed. So better stay with that, while providing copies in the old path temporarily as a transition facility. That would give devs and maintainers of external libs some time to update their build scripts.
Katja
Dan Wilcox @danomatika danomatika.com robotcowboy.com
I'm just looking now - in the Mac apps the ".h" files are indeed in Contents/Resources/src/ as they were before. So unless I'm missing something the procedure to build externs shouldn't have changed. But am I missing something...?
cheers Miller
On Sun, Dec 03, 2017 at 03:22:34PM +0100, katja wrote:
On Sun, Dec 3, 2017 at 1:04 PM, Dan Wilcox danomatika@gmail.com wrote:
If the intention is to leave out sources from future binary distributions for all platforms, would it be an idea to include a copy of the API files in the old path (src) during a transition period, say until the next major version?
Right. If the requirement is that the headers need to be in a "src" folder instead of "include", I can fix that no problem as it was just a cleanup detail I've not gotten around to fixing.
Sorry, my phrasing wasn't completely unambiguous but I meant to say 'a copy of the API files in the old path, in addition to the API files in the new path.' For API files alone, 'include' is the conventional directory indeed. So better stay with that, while providing copies in the old path temporarily as a transition facility. That would give devs and maintainers of external libs some time to update their build scripts.
Katja
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
well, it is not for 0.48-0, there's a new include folder instead, see http://msp.ucsd.edu/Software/pd-0.48-0.mac.tar.gz
2017-12-03 17:06 GMT-02:00 Miller Puckette msp@ucsd.edu:
I'm just looking now - in the Mac apps the ".h" files are indeed in Contents/Resources/src/ as they were before. So unless I'm missing something the procedure to build externs shouldn't have changed. But am I missing something...?
cheers Miller
On Sun, Dec 03, 2017 at 03:22:34PM +0100, katja wrote:
On Sun, Dec 3, 2017 at 1:04 PM, Dan Wilcox danomatika@gmail.com wrote:
If the intention is to leave out sources from future binary distributions for all platforms, would it be an idea to include a copy of the API files in the old path (src) during a transition period, say until the next major version?
Right. If the requirement is that the headers need to be in a "src"
folder
instead of "include", I can fix that no problem as it was just a
cleanup
detail I've not gotten around to fixing.
Sorry, my phrasing wasn't completely unambiguous but I meant to say 'a copy of the API files in the old path, in addition to the API files in the new path.' For API files alone, 'include' is the conventional directory indeed. So better stay with that, while providing copies in the old path temporarily as a transition facility. That would give devs and maintainers of external libs some time to update their build scripts.
Katja
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I changed it back from "include" to a "src" folder after Katja's issue a few months ago, so the current master uses "src". If we do want to transition to an a more standard "include" folder, the best way would be to place the header in "include" and make a symlink to "src" for now. Just to make sure, I believe we are only talking about the macOS .app bundle so using a relative symlink shouldn't be a problem.
On Dec 3, 2017, at 8:11 PM, Alexandre Torres Porres porres@gmail.com wrote:
well, it is not for 0.48-0, there's a new include folder instead, see http://msp.ucsd.edu/Software/pd-0.48-0.mac.tar.gz http://msp.ucsd.edu/Software/pd-0.48-0.mac.tar.gz
2017-12-03 17:06 GMT-02:00 Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu>: I'm just looking now - in the Mac apps the ".h" files are indeed in Contents/Resources/src/ as they were before. So unless I'm missing something the procedure to build externs shouldn't have changed. But am I missing something...?
cheers Miller
On Sun, Dec 03, 2017 at 03:22:34PM +0100, katja wrote:
On Sun, Dec 3, 2017 at 1:04 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
If the intention is to leave out sources from future binary distributions for all platforms, would it be an idea to include a copy of the API files in the old path (src) during a transition period, say until the next major version?
Right. If the requirement is that the headers need to be in a "src" folder instead of "include", I can fix that no problem as it was just a cleanup detail I've not gotten around to fixing.
Sorry, my phrasing wasn't completely unambiguous but I meant to say 'a copy of the API files in the old path, in addition to the API files in the new path.' For API files alone, 'include' is the conventional directory indeed. So better stay with that, while providing copies in the old path temporarily as a transition facility. That would give devs and maintainers of external libs some time to update their build scripts.
Katja
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I think it's fine to leave it as 'src'. Perhaps later (0.49?) it will turn out to be feasible to throw the c files there too.
cheers Miller On Sun, Dec 03, 2017 at 09:29:28PM +0100, Dan Wilcox wrote:
I changed it back from "include" to a "src" folder after Katja's issue a few months ago, so the current master uses "src". If we do want to transition to an a more standard "include" folder, the best way would be to place the header in "include" and make a symlink to "src" for now. Just to make sure, I believe we are only talking about the macOS .app bundle so using a relative symlink shouldn't be a problem.
On Dec 3, 2017, at 8:11 PM, Alexandre Torres Porres porres@gmail.com wrote:
well, it is not for 0.48-0, there's a new include folder instead, see http://msp.ucsd.edu/Software/pd-0.48-0.mac.tar.gz http://msp.ucsd.edu/Software/pd-0.48-0.mac.tar.gz
2017-12-03 17:06 GMT-02:00 Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu>: I'm just looking now - in the Mac apps the ".h" files are indeed in Contents/Resources/src/ as they were before. So unless I'm missing something the procedure to build externs shouldn't have changed. But am I missing something...?
cheers Miller
On Sun, Dec 03, 2017 at 03:22:34PM +0100, katja wrote:
On Sun, Dec 3, 2017 at 1:04 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
If the intention is to leave out sources from future binary distributions for all platforms, would it be an idea to include a copy of the API files in the old path (src) during a transition period, say until the next major version?
Right. If the requirement is that the headers need to be in a "src" folder instead of "include", I can fix that no problem as it was just a cleanup detail I've not gotten around to fixing.
Sorry, my phrasing wasn't completely unambiguous but I meant to say 'a copy of the API files in the old path, in addition to the API files in the new path.' For API files alone, 'include' is the conventional directory indeed. So better stay with that, while providing copies in the old path temporarily as a transition facility. That would give devs and maintainers of external libs some time to update their build scripts.
Katja
Dan Wilcox @danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at mailto:Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev https://lists.puredata.info/listinfo/pd-dev
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Sun, Dec 3, 2017 at 9:29 PM, Dan Wilcox danomatika@gmail.com wrote:
I changed it back from "include" to a "src" folder after Katja's issue a few months ago, so the current master uses "src". If we do want to transition to an a more standard "include" folder, the best way would be to place the header in "include" and make a symlink to "src" for now. Just to make sure, I believe we are only talking about the macOS .app bundle so using a relative symlink shouldn't be a problem.
This solution seems most future-proof. If the full sources would come back in a future release, API files and symlink can swap location. The layout would then be as in pre-0.48-0 with the addition of 'include' symlink to the API. If the sources will not come back, you still have the symlink for compatibility with pre-0.48.0 layout. And in the meantime, till the decision about full sources is made, at least we need not worry about where the API will be in every subsequent release.
Katja
Dan Wilcox @danomatika danomatika.com robotcowboy.com
-
Alexandre Torres Porres -
Dan Wilcox -
katja -
Miller Puckette