[PD] PD and MacIntel

[Hans-Christoph Steiner]

On Oct 31, 2006, at 3:52 AM, Steffen wrote:
> On 30/10/2006, at 20.30, Hans-Christoph Steiner wrote:
>> On Oct 30, 2006, at 4:04 AM, Steffen wrote:
>>> On 29/10/2006, at 22.20, Hans-Christoph Steiner wrote:
>>>> On Oct 29, 2006, at 7:28 AM, Steffen wrote:
>>>>> On 29/10/2006, at 2.34, Hans-Christoph Steiner wrote:
>>>>>
>>>>>> I think that Intel and PowerPC should ultimately be on the  
>>>>>> same page, since 95% of it is probably the same.  The idea is  
>>>>>> to take the content from /docs/developer/darwin and put it  
>>>>>> into this wiki page, then redirect it to the wiki page.
>>>>>
>>>>> Yes, i see your point, i agree.
>>>>>
>>>>> What i'd like to see in such a page is a table describing what  
>>>>> libs (ie. Fink packages) a given external depend on. I mean,  
>>>>> that would indeed please the curious reader/user.
>>>>
>>>> Sounds good, perhaps a wiki page for that?  Usually, its a  
>>>> question of who does the work to keep it up to date, hopefully  
>>>> being a wiki will help with that.
>>>>
>>>> https://puredata.org/docs/developer/Dependencies
>>>
>>> I guess externals overtime can alter there dependencies list,  
>>> hence making such list/table writable for all would be ideal to  
>>> keep it update - so yes, i agree.
>>>
>>> But could I fx. start do the job? Where/how do i find out what a  
>>> given external depend on, and what externals there are (in pd- 
>>> extended)? That is, if i knew, i might have done it already. Can  
>>> it be pulled out of the ./configure info?
>>
>> You could start with the .libs files, they specify addition libs  
>> to link in:  find ~/cvs/pure-data/externals/ -name '*.libs'
> Ok, thanks. I'll see to that.

>>>>> Also such information could be used in the hypothetical  
>>>>> situation where a user wouldn't want to do a complete pd- 
>>>>> extended build, but rather a subset - that is, with only a  
>>>>> subset of the externals included.
>>>>
>>>> Yeah, I think we should have that ability.  I think the best way  
>>>> to achieve that is with a autoconf/configure.  Then it would  
>>>> automatically find dependencies and build what it can considering.
>>>
>>>
>>> Yes, good idea. Though the users will still need the above list  
>>> of dependencies in order to install the dependencies needs to  
>>> build a given subset of pd-extended. It might be a nice to have  
>>> feature to be able to supply a list of externals one would want  
>>> build, in the hypothetical situation where one have the  
>>> dependencies for a given external but still don't want to build  
>>> it into the subset of pd-extended.
>>
>> That shouldn't be too hard with autoconf.
>
> Ok. I thought it would be like supplying a list of wanted externals  
> to ./configure. But ofcause i don't know autoconf.

Something like this:

By default, it would try to build every it can.  Otherwise, you would  
use flags.  For example, to build just motex:

./configure --disable-all-externals --enable-motex

Or to enable something that's off by default:

./configure --enable-pyext

>>>> Its just a matter of someone doing the work.
>>>
>>> Yes. I don't think the demand will be huge (might only be me),  
>>> and the dependencies list will be somehow needed. So it could be  
>>> left fairly low prioritized on a todo-list somewhere. But in the  
>>> realm of making a comprenhencive documentation on how to obtain  
>>> different "configurations" of  Pd i think it would be needed.
>>
>> Its bigger that you think, plus it will be helpful in many other  
>> ways.  For example, it would handle platform differences  
>> automatically, which means we could stop doing it manually.
>
> Could you clarify how it is bigger then i think?

Meaning that it will solve a number of other problems as well.   
Sorry, I got to stop writing strange slang using words about size  
(previously I said "that is huge!", causing some  
misunderstanding...).  The slang is, when you say something is "big"  
or "huge"  that means its really a good thing.

> Will it handle different platform builds automatically by just  
> skipping an external in the build list that happens not to be  
> supported for the given platform that the build is for (, but works  
> for other platforms)?

Basically, ./configure looks for libs.  Then when building, things  
will only build if all the required libs where found.

.hc

------------------------------------------------------------------------

I spent 33 years and four months in active military service and  
during that period I spent most of my time as a high class muscle man  
for Big Business, for Wall Street and the bankers.      - General  
Smedley Butler