On May 24, 2009, at 3:54 PM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
my point has always been quite clear, that i do not especially
like the
idea putting every single line of source we can get our hands on and
which some piece of software eventually included by Pd-extended
depends
on into the repository.
i'd purge GemLibs alltogether rather sooner than later (afaik it is
currently entirely dysfunctional; but you never know and that is the
main reason why it is still there...) and instead revive the idea of
providing GemLib-packages with pre-compiled binaries of the
dependencies.
I am suggesting managing the avdec source code in our SVN, not
binaries. That's what I thought GemLibs was for.
yes, that what GemLib is/was for and and i still want to get rid of
the pd-gem svn part of GemLib.
I agree managing binaries in SVN is not a very good idea as a
general practice.
yes, i guess we are totally in accordance here.
That said, I feel I must reiterate: SVN is a very useful tool for
managing source code, and that's what we are talking about.
indeed.
I am
[...]
I have
[...]
Bottom line, I have
[...]
i have (and had) no intention to question your qualifications.
sorry if i sound a bit mr.know-it-all.
I think that it will be the least work to import avdec into our SVN
and use it from there until it is in the package management of the
supported platforms.
Can we put this issue of importing source code to rest? This is
standard, very common, and indeed a very labor saving practice.
please hold on.
i thought you was asking people (including me) for their opinion.
if you don't care about aberrant opinions, then please don't ask.
i was always joking about "putting the linux-kernel into the /
sources section, since the entire linux-part of Pd-extended
certainly depends on the kernel".
this punchline of this joke was of course, that the linux-kernel is
rather big compared to the entire Pd-extended source-base, and that
this practice tends to include the entire world, which i think is a
waste of ressources (probably a european green attitude).
i am shocked, that the punchline no longer holds: the current /
source folder holds about 322 Megabyte (without any revisions or
such) of sources which have absolutely nothing to do with Pd (in a
sense that probably none of the main developers of any of the
included packages have ever heard of Pure data)
the linux sources for 2.6.26 (with all debian patches applied) is
about 317MB...
finally, i was wondering what i have to do in order to use
gmerlin_avdec
in Gem (which has not been yet done; i suppose you did not break the
entire code-base on your way to porting it to osx/w32 ;-))
Its installed on the Mac OS X build farm machines already. We are
working on getting into the Windows build machine.
ah i see. so it's mainly about getting Gem compiling on w32 with gcc/
autotools.
this reminds me: sorry that i was unable to attend the mingw hack
party on IRC; i had forgotten that i had another long-planned date...
Jokes are all fine and good, I guess I was being too earnest. I was
trying to have a productive conversation. So we both just spent a
fair amount of time on this discussion and as far as I can tell, we
are not any closer a solution for managing gmerlin-avdec.
So, anyone have any specific objections about how importing gmerlin-
avdec code into the pure-data SVN might cause harm? Or any better
solutions for managing gmerlin-avdec?
.hc
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
