[PD] PD and MacIntel

[Steffen]

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.


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

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

Best, Steffen