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