Re: [PD] Purr Data beta 2

[Matt Barber]

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  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-requ...@lists.iem.at wrote:
>
> *From: *IOhannes m zmölnig 
> *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/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

> 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

Re: [PD] Purr Data beta 2

[Roman Haefeli]

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 
> 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-requ...@lists.iem.at wrote:
> > > 
> > > From: IOhannes m zmölnig 
> > > 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

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Question about the pd-extended history

[Ivica Ico Bukvic]

Does anyone have a link to a paper or a publication that documents the 
motivation behind and original initiators of the pd-extended? I traced 
releases back to 2003 but there is no info on who were original players 
who started it. Thank you.


Best,

--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Creative Technologies in Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

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 
danomatika.com 
robotcowboy.com 
> On Oct 10, 2016, at 12:14 PM, Jonathan Wilkes  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

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via 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.


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

Re: [PD] Purr Data beta 2

[Dan Wilcox]

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 
danomatika.com 
robotcowboy.com 
> On Oct 10, 2016, at 12:03 PM, Jonathan Wilkes  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

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Question about the pd-extended history

[Alexandre Torres Porres]

I'm curious to know which were (all) the releases and the dates they were
released

2016-10-10 15:07 GMT-03:00 Jonathan Wilkes via Pd-list :

> > Does anyone have a link to a paper or a publication that documents the
>
>
> > motivation behind and original initiators of the pd-extended? I traced
> > releases back to 2003 but there is no info on who were original players
> > who started it. Thank you.
>
> Didn't Hans start it?
>
> > Best,
>
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Creative Technologies in Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> www.performingarts.vt.edu
> disis.music.vt.edu
> l2ork.music.vt.edu
> ico.bukvic.net
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

> 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
   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Question about the pd-extended history

[Jonathan Wilkes via Pd-list]

> Does anyone have a link to a paper or a publication that documents the 


> motivation behind and original initiators of the pd-extended? I traced 
> releases back to 2003 but there is no info on who were original players 
> who started it. Thank you.

Didn't Hans start it?

> Best,

-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Creative Technologies in Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Question about the pd-extended history

[Ivica Ico Bukvic]

On 10/10/2016 2:07 PM, Jonathan Wilkes wrote:

> Does anyone have a link to a paper or a publication that documents the


> motivation behind and original initiators of the pd-extended? I traced
> releases back to 2003 but there is no info on who were original players
> who started it. Thank you.

Didn't Hans start it?


That's what I thought but I am not 100% sure, so I am hoping the 
community will provide needed clarity.


Best,

Ico



> Best,

--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Creative Technologies in Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net


___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Alexandre Torres Porres]

I get this when trying to download beta 2 for mac

https://git.purrdata.net/jwilkes/purr-data-binaries/raw/master/purr-data-osx64-beta2.zip


404
The page you're looking for could not be found.

2016-10-10 15:26 GMT-03:00 Dan Wilcox :

> 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 
> danomatika.com
> robotcowboy.com
>
> On Oct 10, 2016, at 12:14 PM, Jonathan Wilkes  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
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via 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]  does homebrew support building packages on OSX 10.11 
for an earlier version of OSX, like 10.6?[13:51]  well, i 
guess i should say earlier _versions_, like compatible with 10.6 and 
up...[14:36]  doubting_thomas: no
[15:01]  tdsmith: thanks.[15:05]  doubting_thomas: 
sorry, yw
-Jonathan   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via 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-osx64-beta2.1.zip
-Jonathan



  From: Alexandre Torres Porres 
 To: Jonathan Wilkes  
Cc: Pd-List 
 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-osx64-beta2.zip



404

The page you're looking for could not be found.

2016-10-10 15:26 GMT-03:00 Dan Wilcox :

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





   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

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 
danomatika.com 
robotcowboy.com 
> On Oct 10, 2016, at 2:10 PM, Jonathan Wilkes  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]  does homebrew support building packages on OSX 
> 10.11 for an earlier version of OSX, like 10.6?
> [13:51]  well, i guess i should say earlier _versions_, like 
> compatible with 10.6 and up...
> [14:36]  doubting_thomas: no
> [15:01]  tdsmith: thanks.
> [15:05]  doubting_thomas: sorry, yw
> 
> -Jonathan

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] MIDI issue with Purr Data beta 2 or Pd-Extended

[Alexandre Torres Porres]

Howdy, anybody ever had a problem with MIDI input in PD where it would
always send a "zero" value from a korg keyboard controller?

A student of mine was having this problem, we tested it with  Data beta 2
and Pd-Extended, same issue

but it worked on vanilla 0.47-1

tested with mac and windows...

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Question about the pd-extended history

[Derek Kwan]

> On 10/10/2016 2:07 PM, Jonathan Wilkes wrote:
> >> Does anyone have a link to a paper or a publication that documents the
> >
> >
> >> motivation behind and original initiators of the pd-extended? I traced
> >> releases back to 2003 but there is no info on who were original players
> >> who started it. Thank you.
> >
> >Didn't Hans start it?
> 
> That's what I thought but I am not 100% sure, so I am hoping the community
> will provide needed clarity.

I've been doing some mailing-list archive digging and so far this is the
earlier mention I've found of it on the oft-neglected pd-announce list
so it at least goes back to december 2002. 

https://lists.puredata.info/pipermail/pd-announce/2002-12/000178.html

In terms of pd-list, the earliest mention I've found goes back to May
2003.

https://lists.puredata.info/pipermail/pd-list/2003-05/011695.html

Derek

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via Pd-list]

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 
 To: Matt Barber ; Dan Wilcox  
Cc: Pd-List 
 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


   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

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.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Oct 10, 2016, at 9:30 AM, Jonathan Wilkes  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 
> 
> 
> 
> 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

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Jonathan Wilkes via 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
   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

> 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 
danomatika.com 
robotcowboy.com 
> On Oct 10, 2016, at 7:31 AM, Jonathan Wilkes  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.
> 
> 
> 
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Purr Data beta 2

[Dan Wilcox]

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 

FYI currently the portaudio package cannot build for universal due to a 
configure check.


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
> On Oct 10, 2016, at 8:30 AM, Jonathan Wilkes  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 
> To: Matt Barber ; Dan Wilcox  
> Cc: Pd-List 
> 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 
> 
> 
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list