On Jun 27, 2017, at 9:18 AM, pd-list-request@lists.iem.at wrote:
Do you have Homebrew installed? This will make your life easier.
$ brew install autoconf
Building Pd on a Mac is a bit more difficult than previous replies have suggested. I can't recall, but you may need to also install:
$ brew install automake $ brew install libtool
As mentioned in my previous mail, once we have a stable source distribution tarball after the next release, you will not need autoconf/automake/libtool in order to build Pd on macOS. The autotools are only needed if you're building from the git repo. This is normal behavior for autotools project and those on Linux as well.
You will need to install Tcl. The mac/osx-app.sh says it will do this for you but it won't. Go here and download 8.6.6.X https://www.activestate.com/activetcl/downloads https://www.activestate.com/activetcl/downloads
Nope. I wrote the script and I think you're misinterpreting what it does. It does NOT install Tcl/Tk to your system.
The osx-app.sh script builds the Pd mac app by taking the Wish.app for the requested version of Tcl/Tk, renaming it, and then packing it with all the guts of the pd build for it to work.
The default behavior is to build the app using the included (zipped) Tcl/TK 8.4 Wish.app in the mac folder. What you are referring to is the ability to set the requested version of Tk which can either use the version included in the OS (*not* recommended at this point, TK 8.5 has major issues gui-wise for Pd) or it can build using a newer version of Tcl/Tk.
For the second option, the script then calls the tcltk-wish.sh script which simply downloads the Tcl/Tk sources for the requested version, builds the Wish.app as specified (required architectures aka 32 bit or 64 bit or both), and then the sox-app.sh script uses this newer wish to create the Pd app bundle. It installs the Tcl/Tk inside as well, so there is NO NEED to install this custom/newer version system wide. I thought it best to continue the practice of not requiring the user to alter their system in order to use Pd :)
Also, if you, like me, end up doing lots of builds of Pd with different versions of Tcl/Tk, you can use the tcltk-wish.sh script directly to build the Wish.app for different versions. Then you can use the osx-app.sh with the -w option to specific which existing Wish.app to use. All of this is documented in the --help printout for both scripts.
But then the problem is that the mac/osx-app.sh script hardcodes the wrong path... you'll need to change the following:
cp -R $verbose /System/Library/Frameworks/Tk.framework/Versions/$SYS_TK/Resources/Wish.app .
cp -R $verbose /Library/Frameworks/Tk.framework/Versions/$SYS_TK/Resources/Wish.app .
(Basically just remove "/System" because your system Tk is now the one you just installed.)
As mentioned above, this is not necessary and can be overridden by using the script command line options. Check --help.
This will allow you to ./osx-app.sh -s 0.47-1 which will create Pd-0.47-1.app and then you can safely delete the "-0.47-1". (I don't know why anyone thought adding this was mandatory...)
The historical naming convention allows you to have and use multiple versions of Pd at the same time. Quite useful. OTOH I've been looking into renaming the app as suggested and writing the version string into the app bundle plist as per a "normal" macOS app.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Tue, 27 Jun 2017, at 07:20 PM, Dan Wilcox wrote:
You will need to install Tcl. The mac/osx-app.sh says it will do this for you but it won't. Go here and download 8.6.6.X https://www.activestate.com/activetcl/downloads https://www.activestate.com/activetcl/downloads
Nope. I wrote the script and I think you're misinterpreting what it does. It does NOT install Tcl/Tk to your system.
The osx-app.sh script builds the Pd mac app by taking the Wish.app for the requested version of Tcl/Tk, renaming it, and then packing it with all the guts of the pd build for it to work.
The default behavior is to build the app using the included (zipped) Tcl/TK 8.4 Wish.app in the mac folder. What you are referring to is the ability to set the requested version of Tk which can either use the version included in the OS (*not* recommended at this point, TK 8.5 has major issues gui-wise for Pd) or it can build using a newer version of Tcl/Tk.
For the second option, the script then calls the tcltk-wish.sh script which simply downloads the Tcl/Tk sources for the requested version, builds the Wish.app as specified (required architectures aka 32 bit or 64 bit or both), and then the sox-app.sh script uses this newer wish to create the Pd app bundle. It installs the Tcl/Tk inside as well, so there is NO NEED to install this custom/newer version system wide. I thought it best to continue the practice of not requiring the user to alter their system in order to use Pd :)
Yeah sorry, it has been a little while since I tried these options and forgot how it worked internally. However the upshot was that none of these methods worked for me, hence ActiveTcl. I really wanted the tarball method to work, but it would just create an app package that crashed on launch. The logs suggested the framework wasn't present. After a bunch of trial and error, installing ActiveTcl was the only thing I could make work.
Also, if you, like me, end up doing lots of builds of Pd with different versions of Tcl/Tk, you can use the tcltk-wish.sh script directly to build the Wish.app for different versions. Then you can use the osx-app.sh with the -w option to specific which existing Wish.app to use. All of this is documented in the --help printout for both scripts.
But then the problem is that the mac/osx-app.sh script hardcodes the wrong path... you'll need to change the following:
cp -R $verbose /System/Library/Frameworks/Tk.framework/Versions/$SYS_TK/Resources/Wish.app .
cp -R $verbose /Library/Frameworks/Tk.framework/Versions/$SYS_TK/Resources/Wish.app .
(Basically just remove "/System" because your system Tk is now the one you just installed.)
As mentioned above, this is not necessary and can be overridden by using the script command line options. Check --help.
Ah yes, sorry I stand corrected. The above hack came from a PR I was going to submit about the script looking for the framework in /Library first, then falling back on /System, so the user can just type
$ ./osx-app.sh -s 8.6 VERSION
instead of
$ ./osx-app.sh -w /Library/Frameworks/Tk.framework/Versions/Current/Resources/Wish.app VERSION
So, no hacking necessary, but I found the hacking easier than remembering where Wish was.
This will allow you to ./osx-app.sh -s 0.47-1 which will create Pd-0.47-1.app and then you can safely delete the "-0.47-1". (I don't know why anyone thought adding this was mandatory...)
The historical naming convention allows you to have and use multiple versions of Pd at the same time. Quite useful. OTOH I've been looking into renaming the app as suggested and writing the version string into the app bundle plist as per a "normal" macOS app.
I agree the naming convention is useful. I don't think the build should fail without it though.
Appreciate your work on Pd/GEM :)
On Jun 27, 2017, at 11:42 AM, Paul Rankin hello@paulwrankin.com wrote:
Yeah sorry, it has been a little while since I tried these options and forgot how it worked internally. However the upshot was that none of these methods worked for me, hence ActiveTcl. I really wanted the tarball method to work, but it would just create an app package that crashed on launch. The logs suggested the framework wasn't present. After a bunch of trial and error, installing ActiveTcl was the only thing I could make work.
In the future, it would be helpful for us to know if the included scripts are not working so we can check & fix them :)
My entire goal of the autotools update was to make building Pd easier so user testing is important.
Ah yes, sorry I stand corrected. The above hack came from a PR I was going to submit about the script looking for the framework in /Library first, then falling back on /System, so the user can just type
$ ./osx-app.sh -s 8.6 VERSION
instead of
$ ./osx-app.sh -w /Library/Frameworks/Tk.framework/Versions/Current/Resources/Wish.app VERSION
So, no hacking necessary, but I found the hacking easier than remembering where Wish was.
I can add this behavior. I built the script with only the system installed Tcl/Tk to check. Good to know the location of the custom ActiveState install.
I agree the naming convention is useful. I don't think the build should fail without it though.
I was a bit lazy there as there isn't an easy way to grab the version string without parsing the first line in configure.ac. Your suggestion of just leaving it off without the version argument is even easier. I believe I *did* add the version string info already in a previous commit.
Appreciate your work on Pd/GEM :)
Thanks
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Tue, 27 Jun 2017, at 07:56 PM, Dan Wilcox wrote:
In the future, it would be helpful for us to know if the included scripts are not working so we can check & fix them :)
My entire goal of the autotools update was to make building Pd easier so user testing is important.
Cool. I will redo my build steps next week and report back.
Could the functionality of the mac/*.sh scripts be incorporated into the Makefile? This feels neater to me.
Ah yes, sorry I stand corrected. The above hack came from a PR I was going to submit about the script looking for the framework in /Library first, then falling back on /System, so the user can just type
$ ./osx-app.sh -s 8.6 VERSION
instead of
$ ./osx-app.sh -w /Library/Frameworks/Tk.framework/Versions/Current/Resources/Wish.app VERSION
So, no hacking necessary, but I found the hacking easier than remembering where Wish was.
I can add this behavior. I built the script with only the system installed Tcl/Tk to check. Good to know the location of the custom ActiveState install.
One caveat here is that I'm pretty sure the framework location changed from 8.4 or 8.5, or maybe on the macOS side... Not sure. But I do recall the ActiveTcl documentation having an outdated path listed. Maybe there is a more programatic way of finding the framework...
I agree the naming convention is useful. I don't think the build should fail without it though.
I was a bit lazy there as there isn't an easy way to grab the version string without parsing the first line in configure.ac. Your suggestion of just leaving it off without the version argument is even easier. I believe I *did* add the version string info already in a previous commit.
I was being even lazier... I was going to open a PR to make VERSION optional in the script, but then I didn't and just complained about it instead.
On Jun 27, 2017, at 1:05 PM, Paul Rankin hello@paulwrankin.com wrote:
Cool. I will redo my build steps next week and report back.
As requested: https://github.com/pure-data/pure-data/pull/71 https://github.com/pure-data/pure-data/pull/71
Could the functionality of the mac/*.sh scripts be incorporated into the Makefile? This feels neater to me.
The basic aspect is, via: make app
Anything more, I feel, means the user can interact with the scripts directly. As it is now, "make app" produces the default app bundle using the included Wish as per Miller's builds. This is the safest, most supported approach so far. At some point when the newer Tk aspects are smoothed out (font sizing, etc), we can update that build target.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/