I use Homebrew all the time. It’s great. Definitely nicer to use than macports.
I prefer Homebrew as it uses as many of the built in programs and libs already on OSX. That means it’s *much* faster to install/build packages since most things don’t require as many dependencies. You can, of course, also install packages to supersede the often older versions that come with the OS.
Also, it uses the more standard /usr/local as opposed to Macport’s /opt, so most build systems find things automatically.
One more point, Homebrew has prebuilt binaries as well so installing *big things* is relatively quick too.
Actually, when Jonathan sent me the purr data wiki, I did a quick check and pretty much all of the libs y’all install via macports are available in Hombrew.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 9, 2016, at 11:35 PM, pd-list-request@lists.iem.at wrote:
From: IOhannes m zmölnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> Subject: Re: [PD] Purr Data beta 2 Date: October 9, 2016 at 3:20:17 PM MDT To: pd-list@lists.iem.at mailto:pd-list@lists.iem.at
On 10/09/2016 11:09 PM, Matt Barber wrote:
Thanks for this, IOhannes. We've been using macports for most of the development of purr-data on OSX (with a couple of fink installs for some libraries). Do you find brew to be superior, or was this a comfortable default?
i cannot really remember what led to the actual decision. maybe brew was just the cool kid when i looked into it...
however, i'm under the impression that so far i have had far less troubles with brew than with fink and or macports. keep in mind, that i hardly ever use any of these in real live. (so while i probably find brew to be superior, i have virtually zero data points to be able to defend this position).
gfmd IOhannes
Thank you. /usr/local always seems iffy to me, but this is after years in linux making sure to make packages to install any software via package manager. The thing I liked about macport's /opt, which is actually something of a standard for non-pacakge-managed software in linux, is that it's relatively encapsulated away from the rest of the directory structure. But as long as it does a reasonable job of uninstalling everything in a package it should be fine.
On Mon, Oct 10, 2016 at 1:44 AM, Dan Wilcox danomatika@gmail.com wrote:
I use Homebrew all the time. It’s great. Definitely nicer to use than macports.
I prefer Homebrew as it uses as many of the built in programs and libs already on OSX. That means it’s *much* faster to install/build packages since most things don’t require as many dependencies. You can, of course, also install packages to supersede the often older versions that come with the OS.
Also, it uses the more standard /usr/local as opposed to Macport’s /opt, so most build systems find things automatically.
One more point, Homebrew has prebuilt binaries as well so installing *big things* is relatively quick too.
Actually, when Jonathan sent me the purr data wiki, I did a quick check and pretty much all of the libs y’all install via macports are available in Hombrew.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com robotcowboy.com
On Oct 9, 2016, at 11:35 PM, pd-list-request@lists.iem.at wrote:
*From: *IOhannes m zmölnig zmoelnig@iem.at *Subject: **Re: [PD] Purr Data beta 2* *Date: *October 9, 2016 at 3:20:17 PM MDT *To: *pd-list@lists.iem.at
On 10/09/2016 11:09 PM, Matt Barber wrote:
Thanks for this, IOhannes. We've been using macports for most of the development of purr-data on OSX (with a couple of fink installs for some libraries). Do you find brew to be superior, or was this a comfortable default?
i cannot really remember what led to the actual decision. maybe brew was just the cool kid when i looked into it...
however, i'm under the impression that so far i have had far less troubles with brew than with fink and or macports. keep in mind, that i hardly ever use any of these in real live. (so while i probably find brew to be superior, i have virtually zero data points to be able to defend this position).
gfmd IOhannes
Thank you. /usr/local always seems iffy to me, but this is after years in linux making sure to make packages to install any software via package manager. The thing I liked about macport's /opt, which is actually something of a standard for non-pacakge-managed software in linux, is that it's relatively encapsulated away from the rest of the directory structure. But as long as it does a reasonable job of uninstalling everything in a package it should be fine.
Does Homebrew require XCode? If so then speed of package installs is insignificant by comparison. If not then I'll give it a try-- that would reduce the total time to build from 1 day to something less obnoxious. -Jonathan
One more Homebrew question:Does homebrew let me do the equivalent of -mmacosx-version-min ? Can I ask it for a libsdl package that runs on 10.4 and greater? -Jonathan
From: Jonathan Wilkes via Pd-list <pd-list@lists.iem.at>
To: Matt Barber brbrofsvl@gmail.com; Dan Wilcox danomatika@gmail.com Cc: Pd-List pd-list@lists.iem.at Sent: Monday, October 10, 2016 9:31 AM Subject: Re: [PD] Purr Data beta 2
Thank you. /usr/local always seems iffy to me, but this is after years in linux making sure to make packages to install any software via package manager. The thing I liked about macport's /opt, which is actually something of a standard for non-pacakge-managed software in linux, is that it's relatively encapsulated away from the rest of the directory structure. But as long as it does a reasonable job of uninstalling everything in a package it should be fine.
Does Homebrew require XCode? If so then speed of package installs is insignificant by comparison. If not then I'll give it a try-- that would reduce the total time to build from 1 day to something less obnoxious. -Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
The closest might be -universal which asks to build/install a universal 32/64 bit package. There might be something else, but you’ll need to check the docs: http://brew.sh http://brew.sh/
FYI currently the portaudio package cannot build for universal due to a configure check.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 10, 2016, at 8:30 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
One more Homebrew question: Does homebrew let me do the equivalent of -mmacosx-version-min ? Can I ask it for a libsdl package that runs on 10.4 and greater?
-Jonathan
From: Jonathan Wilkes via Pd-list pd-list@lists.iem.at To: Matt Barber brbrofsvl@gmail.com; Dan Wilcox danomatika@gmail.com Cc: Pd-List pd-list@lists.iem.at Sent: Monday, October 10, 2016 9:31 AM Subject: Re: [PD] Purr Data beta 2
Thank you. /usr/local always seems iffy to me, but this is after years in linux making sure to make packages to install any software via package manager. The thing I liked about macport's /opt, which is actually something of a standard for non-pacakge-managed software in linux, is that it's relatively encapsulated away from the rest of the directory structure. But as long as it does a reasonable job of uninstalling everything in a package it should be fine.
Does Homebrew require XCode? If so then speed of package installs is insignificant by comparison.
If not then I'll give it a try-- that would reduce the total time to build from 1 day to something less obnoxious.
-Jonathan
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
The closest might be -universal which asks to build/install a universal 32/64 bit package. There might be something else, but you’ll need to check the docs: http://brew.sh
Nothing pops out at me. It would be an enormous benefit over Macports-- which doesn't officially support targeting versions earlier than the one you happen to be building against. I assume they'd advertise that front and center.
-Jonathan
Judging from the output of brew —env, there is a MACOSX_DEPLOYMENT_TARGET you should be able to set/override. Simplest way would be when running brew http://stackoverflow.com/questions/23338713/homebrew-how-to-permanently-override-homebrew-cc-homebrew-cxx-env-settings:
MACOSX_DEPLOYMENT_TARGET=10.6 brew …
That, in combination with —build-from-source when installing packages, might give you want you need.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 10, 2016, at 9:30 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
The closest might be -universal which asks to build/install a universal 32/64 bit package. There might be something else, but you’ll need to check the docs: http://brew.sh http://brew.sh/
Nothing pops out at me. It would be an enormous benefit over Macports-- which doesn't officially support targeting versions earlier than the one you happen to be building against. I assume they'd advertise that front and center.
-Jonathan
Judging from the output of brew —env, there is a MACOSX_DEPLOYMENT_TARGET you should be able to set/override. Simplest way would be when running brew:
MACOSX_DEPLOYMENT_TARGET=10.6 brew … That, in combination with —build-from-source when installing packages, might give you want you need.
That could work, but then I'm back to building from source. (macports uses binaries for most stuff, btw.)
I'm happy to investigate further _if_ a homebrew dev says that they officially support installing this way. There's a similar way to change the deployment target for macports. But one of the devs told me that kind of compatibility isn't a design goal and they don't support doing that. -Jonathan
You’ll probably need to build form source in either environment if you want to be sure of the deployment target. Both Homebrew and Macports are focused on running OS software for the current system, much less so for building baked libraries to run on other systems.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 10, 2016, at 12:03 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Judging from the output of brew —env, there is a MACOSX_DEPLOYMENT_TARGET you should be able to set/override. Simplest way would be when running brew http://stackoverflow.com/questions/23338713/homebrew-how-to-permanently-override-homebrew-cc-homebrew-cxx-env-settings:
MACOSX_DEPLOYMENT_TARGET=10.6 brew …That, in combination with —build-from-source when installing packages, might give you want you need.
That could work, but then I'm back to building from source. (macports uses binaries for most stuff, btw.)
I'm happy to investigate further _if_ a homebrew dev says that they officially support installing this way. There's a similar way to change the deployment target for macports. But one of the devs told me that kind of compatibility isn't a design goal and they don't support doing that.
-Jonathan
You’ll probably need to build form source in either environment if you want to be sure of the deployment target. Both Homebrew and Macports are focused on running OS software for the current system, much less so for building baked libraries to run on other systems.
I'm also just assuming that binaries built for the older targets will work on all the newer systems. -Jonathan
Well, the deployment target only *indicates* to the OS if the app should be runnable. It also helps in defining which APIs are allowed. In either, case it’s no guarantee but, if a project is not using anything too new or esoteric, it can run fine on a lot of different versions of systems. In Obj-C, it’s trivial to check if a method or class definition exists at runtime, so you can more easily support a API changes over time without needing to explicitly build on an older system. Of course, this approach is less applicable to C/C++, hence it becomes more of an indication.
See also http://www.cocoabuilder.com/archive/xcode/287223-mac-os-deployment-target.ht... http://www.cocoabuilder.com/archive/xcode/287223-mac-os-deployment-target.html & http://stackoverflow.com/questions/25352389/difference-between-macosx-deploy... http://stackoverflow.com/questions/25352389/difference-between-macosx-deployment-target-and-mmacosx-version-min-compiler-op#25362535
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 10, 2016, at 12:14 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
You’ll probably need to build form source in either environment if you want to be sure of the deployment target. Both Homebrew and Macports are focused on running OS software for the current system, much less so for building baked libraries to run on other systems.
I'm also just assuming that binaries built for the older targets will work on all the newer systems.
-Jonathan
I get this when trying to download beta 2 for mac
https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-osx...
404 The page you're looking for could not be found.
2016-10-10 15:26 GMT-03:00 Dan Wilcox danomatika@gmail.com:
Well, the deployment target only *indicates* to the OS if the app should be runnable. It also helps in defining which APIs are allowed. In either, case it’s no guarantee but, if a project is not using anything too new or esoteric, it can run fine on a lot of different versions of systems. In Obj-C, it’s trivial to check if a method or class definition exists at runtime, so you can more easily support a API changes over time without needing to explicitly build on an older system. Of course, this approach is less applicable to C/C++, hence it becomes more of an indication.
See also http://www.cocoabuilder.com/archive/xcode/287223-mac- os-deployment-target.html & http://stackoverflow.com/ questions/25352389/difference-between-macosx-deployment- target-and-mmacosx-version-min-compiler-op#25362535
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com robotcowboy.com
On Oct 10, 2016, at 12:14 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
You’ll probably need to build form source in either environment if you
want to be sure of the deployment target. Both Homebrew and Macports are focused on running OS software for the current
system, much less so for building baked libraries to run on other
systems.
I'm also just assuming that binaries built for the older targets will work on all the newer systems.
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
I had to push a quick update to fix a freezer bug.
Try:https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-osx... -Jonathan
From: Alexandre Torres Porres <porres@gmail.com>
To: Jonathan Wilkes jancsika@yahoo.com Cc: Pd-List pd-list@lists.iem.at Sent: Monday, October 10, 2016 3:18 PM Subject: Re: [PD] Purr Data beta 2
I get this when trying to download beta 2 for mac https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-osx...
404
The page you're looking for could not be found.
2016-10-10 15:26 GMT-03:00 Dan Wilcox danomatika@gmail.com:
Well, the deployment target only *indicates* to the OS if the app should be runnable. It also helps in defining which APIs are allowed. In either, case it’s no guarantee but, if a project is not using anything too new or esoteric, it can run fine on a lot of different versions of systems. In Obj-C, it’s trivial to check if a method or class definition exists at runtime, so you can more easily support a API changes over time without needing to explicitly build on an older system. Of course, this approach is less applicable to C/C++, hence it becomes more of an indication. See also http://www.cocoabuilder. com/archive/xcode/287223-mac- os-deployment-target.html & ht tp://stackoverflow.com/ questions/25352389/difference- between-macosx-deployment- target-and-mmacosx-version- min-compiler-op#25362535
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Oct 10, 2016, at 12:14 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
You’ll probably need to build form source in either environment if you want to be sure of the deployment target. Both Homebrew and Macports are focused on running OS software for the current system, much less so for building baked libraries to run on other systems.
I'm also just assuming that binaries built for the older targets will work on all the newer systems. -Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
You’ll probably need to build form source in either environment if you want to be sure of the deployment target. Both Homebrew and Macports are focused on running OS software for the current system, much less so for building baked libraries to run on other systems.
From #machomebrew on freenode:
[13:50] <doubting_thomas> does homebrew support building packages on OSX 10.11 for an earlier version of OSX, like 10.6?[13:51] <doubting_thomas> well, i guess i should say earlier _versions_, like compatible with 10.6 and up...[14:36] <tdsmith> doubting_thomas: no [15:01] <doubting_thomas> tdsmith: thanks.[15:05] <tdsmith> doubting_thomas: sorry, yw -Jonathan
As a blanket answer that may be true as that’s not the goal of the project, but technically, it’s totally possible depending on what you’re building. In the end, it’s all just C/C++ libraries you *could* download and build yourself.
The same is true for different versions of Linux distros.
Anyway, I’ll stop talking technical then agree that you probably can’t build for a 10+ year old OSX version on a contemporary one, at least with the amount & type of dependencies you are dealing with. That being said, if it’s easy for people to build it themselves, then it’s simpler to focus on putting out a binary with more recent compatibility like 10.8+. The vast majority of OSX users are using 10.8+.
My test builds of vanilla for OSX seem to work fine back to 10.8. I need to do some more testing to figure out what details I’m missing for it to work on 10.6 & 10.7, but then I’d need a computer running either of those at hand… maybe not worth it since people can much more easily build vanilla for themselves if/when they need to.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 10, 2016, at 2:10 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
You’ll probably need to build form source in either environment if you want to be sure of the deployment target. Both Homebrew and Macports are focused on running OS software for the current system, much less so for building baked libraries to run on other systems.
From #machomebrew on freenode:
[13:50] <doubting_thomas> does homebrew support building packages on OSX 10.11 for an earlier version of OSX, like 10.6? [13:51] <doubting_thomas> well, i guess i should say earlier _versions_, like compatible with 10.6 and up... [14:36] <tdsmith> doubting_thomas: no [15:01] <doubting_thomas> tdsmith: thanks. [15:05] <tdsmith> doubting_thomas: sorry, yw
-Jonathan
You’ll probably need to build form source in either environment if you want to be sure of the deployment target. Both Homebrew and Macports are focused on running OS software for the current system, much less so for building baked libraries to run on other systems.
Ok, so I tried out homebrew on a fresh OSX 10.11 vm. Great speed of installation,
and flawless downloading of necessary packages. And it results in completely
borked external libs-- at least the ones that depend on an external library.
Take oggread~.pd_darwin for example:
With macports:
otool -L oggread~.pd_darwin
gives this:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)/opt/local/lib/libvorbis.0. dylib (compatibility version 5.0.0, current version 5.8.0)/opt/local/lib/libvorbisenc.2. dylib (compatibility version 3.0.0, current version 3.11.0)/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 915.0.0)
When building the app bundle, Hans (I think) wrote a script that can grab the /opt/local/lib dependencies, copy them to the app bundle, and revise the path in the binary using @executable_path to make sure the dependecies in the app bundle are correctly found when loading an external.
Now, with homebrew:otool -L oggread~.pd_darwin
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 915.0.0)
There's no path listed at all to the ogg lib dependencies. When I try to load oggread~ with the Purr Data app bundle I just created it doesn't search /usr/local/lib and consequently reports missing symbols. Any clue how to get the compiler to actually link to the necessary libs when using homebrew? -Jonathan
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Oct 10, 2016, at 12:03 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Judging from the output of brew —env, there is a MACOSX_DEPLOYMENT_TARGET you should be able to set/override. Simplest way would be when running brew:
MACOSX_DEPLOYMENT_TARGET=10.6 brew … That, in combination with —build-from-source when installing packages, might give you want you need.
That could work, but then I'm back to building from source. (macports uses binaries for most stuff, btw.)
I'm happy to investigate further _if_ a homebrew dev says that they officially support installing this way. There's a similar way to change the deployment target for macports. But one of the devs told me that kind of compatibility isn't a design goal and they don't support doing that. -Jonathan
On Oct 12, 2016, at 9:30 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
When building the app bundle, Hans (I think) wrote a script that can grab the /opt/local/lib dependencies, copy them to the app bundle, and revise the path in the binary using @executable_path to make sure the dependecies in the app bundle are correctly found when loading an external.
Yeah, that’s probably using install_name_tool. Here’s an old but relevant discussion on this: http://forums.macrumors.com/threads/embedding-or-statically-linking-against-... http://forums.macrumors.com/threads/embedding-or-statically-linking-against-a-dylib.176077/
Now, with homebrew: otool -L oggread~.pd_darwin
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 915.0.0)
There's no path listed at all to the ogg lib dependencies. When I try to load oggread~ with the Purr Data app bundle I just created it doesn't search /usr/local/lib and consequently reports missing symbols.
I’m not sure. Maybe, try explicitly adding /usr/local/include to the header search path and /usr/local/lib to the linker search path? I’m doing that in the autotools_update brach configure.ac: https://github.com/pure-data/pure-data/blob/autotools_updates/configure.ac#L... https://github.com/pure-data/pure-data/blob/autotools_updates/configure.ac#L62
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
After a bit of finessing, Homebrew seems to be working just fine. One snag-- any idea how to get plugin~ building using only Homebrew libs? I need ladspa.h but there's no package for it. I suppose I can just wget it if nothing else... -Jonathan
From: Dan Wilcox <danomatika@gmail.com>
To: Jonathan Wilkes jancsika@yahoo.com Cc: Matt Barber brbrofsvl@gmail.com; Pd-List pd-list@lists.iem.at Sent: Wednesday, October 12, 2016 11:53 AM Subject: Re: [PD] Purr Data beta 2
On Oct 12, 2016, at 9:30 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
When building the app bundle, Hans (I think) wrote a script that can grab the /opt/local/lib dependencies, copy them to the app bundle, and revise the path in the binary using @executable_path to make sure the dependecies in the app bundle are correctly found when loading an external.
Yeah, that’s probably using install_name_tool. Here’s an old but relevant discussion on this: http://forums.macrumors.com/threads/embedding-or-statically-linking-against-...
Now, with homebrew:otool -L oggread~.pd_darwin
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 915.0.0)
There's no path listed at all to the ogg lib dependencies. When I try to load oggread~ with the Purr Data app bundle I just created it doesn't search /usr/local/lib and consequently reports missing symbols.
I’m not sure. Maybe, try explicitly adding /usr/local/include to the header search path and /usr/local/lib to the linker search path? I’m doing that in the autotools_update brach configure.ac: https://github.com/pure-data/pure-data/blob/autotools_updates/configure.ac#L...
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Oct 14, 2016, at 11:37 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
One snag-- any idea how to get plugin~ building using only Homebrew libs? I need ladspa.h but there's no package for it. I suppose I can just wget it if nothing else…
Should work fine as long as ladspa doesn’t require a ton of dependencies.
I use curl -LO since wget is not installed on OSX by default.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Also, FYI: just noticed this today: https://github.com/Homebrew/brew/blob/master/docs/Analytics.md https://github.com/Homebrew/brew/blob/master/docs/Analytics.md
I can understand the reasoning but, man, am I tired of everything becoming opt-in by default. Looks like you should add the following to your build guide:
export HOMEBREW_NO_ANALYTICS=1
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 14, 2016, at 11:43 AM, Dan Wilcox danomatika@gmail.com wrote:
On Oct 14, 2016, at 11:37 AM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
One snag-- any idea how to get plugin~ building using only Homebrew libs? I need ladspa.h but there's no package for it. I suppose I can just wget it if nothing else…
Should work fine as long as ladspa doesn’t require a ton of dependencies.
I use curl -LO since wget is not installed on OSX by default.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
According to the doc, "brew analytics off" works, too. I can certainly suggest that setting in the instructions.
-Jonathan
Also, FYI: just noticed this today: https://github.com/Homebrew/brew/blob/master/docs/Analytics.md
I can understand the reasoning but, man, am I tired of everything becoming opt-in by default. Looks like you should add the following to your build guide: export HOMEBREW_NO_ANALYTICS=1
Dan Wilcox
@danomatika danomatika.com robotcowboy.com
On Oct 14, 2016, at 11:43 AM, Dan Wilcox danomatika@gmail.com wrote:
On Oct 14, 2016, at 11:37 AM, Jonathan Wilkes jancsika@yahoo.com wrote: One snag-- any idea how to get plugin~ building using only Homebrew libs? I need ladspa.h but there's no package for it. I suppose I can just wget it if nothing else…
Should work fine as long as ladspa doesn’t require a ton of dependencies. I use curl -LO since wget is not installed on OSX by default.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Yeah, I ran that. I was thinking of the following for new users so the install itself is not sent and then the setting is permanent:
export HOMEBREW_NO_ANALYTICS=1 && /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)%E2%80%9D && brew analytics off
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 14, 2016, at 8:54 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
According to the doc, "brew analytics off" works, too. I can certainly suggest that setting in the instructions.
-Jonathan
Also, FYI: just noticed this today: https://github.com/Homebrew/brew/blob/master/docs/Analytics.md https://github.com/Homebrew/brew/blob/master/docs/Analytics.md
I can understand the reasoning but, man, am I tired of everything becoming opt-in by default. Looks like you should add the following to your build guide:
export HOMEBREW_NO_ANALYTICS=1
Dan Wilcox
@danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 14, 2016, at 11:43 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
On Oct 14, 2016, at 11:37 AM, Jonathan Wilkes <jancsika@yahoo.com mailto:jancsika@yahoo.com> wrote:
One snag-- any idea how to get plugin~ building using only Homebrew libs? I need ladspa.h but there's no package for it. I suppose I can just wget it if nothing else…
Should work fine as long as ladspa doesn’t require a ton of dependencies.
I use curl -LO since wget is not installed on OSX by default.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Does Homebrew require XCode? If so then speed of package installs is insignificant by comparison.
If not then I'll give it a try-- that would reduce the total time to build from 1 day to something less obnoxious.
Yes and no. Yes in that you need to install the Xcode Commandline Tools (aka gcc/clang, make, git, etc) and No in that you do not need to download and install the whole Xcode GUI app & tools if you’re only building things on the command line.
As of OSX 10.8 or so, you can run the following to install the commandline tools:
xcode-select —install
This will open a dialog box where you can click “Install”. There is no need for a login, or App Store, or whatever.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 10, 2016, at 7:31 AM, Jonathan Wilkes jancsika@yahoo.com wrote:
Thank you. /usr/local always seems iffy to me, but this is after years in linux making sure to make packages to install any software via package manager. The thing I liked about macport's /opt, which is actually something of a standard for non-pacakge-managed software in linux, is that it's relatively encapsulated away from the rest of the directory structure. But as long as it does a reasonable job of uninstalling everything in a package it should be fine.
On Mon, 2016-10-10 at 09:13 -0400, Matt Barber wrote:
Thank you. /usr/local always seems iffy to me, but this is after years in linux making sure to make packages to install any software via package manager.
/usr/local [1] is exactly meant for _local_ installations that do not interfere with any package management system and has the advantage that binaries in /usr/local/bin and /usr/local/sbin usually are automatically found by shells like bash.
Roman
[1] http://www.pathname.com/fhs/2.2/fhs-4.9.html
On Mon, Oct 10, 2016 at 1:44 AM, Dan Wilcox danomatika@gmail.com wrote:
I use Homebrew all the time. It’s great. Definitely nicer to use than macports.
I prefer Homebrew as it uses as many of the built in programs and libs already on OSX. That means it’s *much* faster to install/build packages since most things don’t require as many dependencies. You can, of course, also install packages to supersede the often older versions that come with the OS.
Also, it uses the more standard /usr/local as opposed to Macport’s /opt, so most build systems find things automatically.
One more point, Homebrew has prebuilt binaries as well so installing *big things* is relatively quick too.
Actually, when Jonathan sent me the purr data wiki, I did a quick check and pretty much all of the libs y’all install via macports are available in Hombrew.
Dan Wilcox @danomatika danomatika.com robotcowboy.com
On Oct 9, 2016, at 11:35 PM, pd-list-request@lists.iem.at wrote:
From: IOhannes m zmölnig zmoelnig@iem.at Subject: Re: [PD] Purr Data beta 2 Date: October 9, 2016 at 3:20:17 PM MDT To: pd-list@lists.iem.at
On 10/09/2016 11:09 PM, Matt Barber wrote:
Thanks for this, IOhannes. We've been using macports for most of the development of purr-data on OSX (with a couple of fink installs for some libraries). Do you find brew to be superior, or was this a comfortable default?
i cannot really remember what led to the actual decision. maybe brew was just the cool kid when i looked into it...
however, i'm under the impression that so far i have had far less troubles with brew than with fink and or macports. keep in mind, that i hardly ever use any of these in real live. (so while i probably find brew to be superior, i have virtually zero data points to be able to defend this position).
gfmd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis tinfo/pd-list
A fresh in stall of OSX does not have a /usr/local directory, so it is encapsulated to a certain extent. Homebrew actually installs things into it’s own location at /usr/local/Cellar and then symlinks to the standard locations.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 10, 2016, at 7:13 AM, Matt Barber brbrofsvl@gmail.com wrote:
Thank you. /usr/local always seems iffy to me, but this is after years in linux making sure to make packages to install any software via package manager. The thing I liked about macport's /opt, which is actually something of a standard for non-pacakge-managed software in linux, is that it's relatively encapsulated away from the rest of the directory structure. But as long as it does a reasonable job of uninstalling everything in a package it should be fine.
On Mon, Oct 10, 2016 at 1:44 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: I use Homebrew all the time. It’s great. Definitely nicer to use than macports.
I prefer Homebrew as it uses as many of the built in programs and libs already on OSX. That means it’s *much* faster to install/build packages since most things don’t require as many dependencies. You can, of course, also install packages to supersede the often older versions that come with the OS.
Also, it uses the more standard /usr/local as opposed to Macport’s /opt, so most build systems find things automatically.
One more point, Homebrew has prebuilt binaries as well so installing *big things* is relatively quick too.
Actually, when Jonathan sent me the purr data wiki, I did a quick check and pretty much all of the libs y’all install via macports are available in Hombrew.
Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Oct 9, 2016, at 11:35 PM, pd-list-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
From: IOhannes m zmölnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> Subject: Re: [PD] Purr Data beta 2 Date: October 9, 2016 at 3:20:17 PM MDT To: pd-list@lists.iem.at mailto:pd-list@lists.iem.at
On 10/09/2016 11:09 PM, Matt Barber wrote:
Thanks for this, IOhannes. We've been using macports for most of the development of purr-data on OSX (with a couple of fink installs for some libraries). Do you find brew to be superior, or was this a comfortable default?
i cannot really remember what led to the actual decision. maybe brew was just the cool kid when i looked into it...
however, i'm under the impression that so far i have had far less troubles with brew than with fink and or macports. keep in mind, that i hardly ever use any of these in real live. (so while i probably find brew to be superior, i have virtually zero data points to be able to defend this position).
gfmd IOhannes
-
Alexandre Torres Porres -
Dan Wilcox -
Jonathan Wilkes -
Matt Barber -
Roman Haefeli