On Dec 15, 2008, at 3:28 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On Dec 12, 2008, at 3:44 PM, IOhannes m zmölnig wrote:
Chris McCormick wrote:
On Fri, Dec 05, 2008 at 01:06:32AM -0500, Hans-Christoph Steiner
wrote:What about the idea of having a separate section like /pure- data/svn- externals?
hmm, i'm trying (not so) hard to remove the ./abstractions folder in favour of a grand unified ./externals folder...
That will take a lot of political organizing, as we saw before.
In the mean time, I don't see much harm in having /pure-data/svn- externalsi am more a fan of gradual migration than of sudden switches. this
allows people to adapt changes at their own pace. sometimes it is a bit hard to do (e.g. when migrating from cvs to
svn), othertimes it is simpler. if we agree that it might be a good idea to merge ./abstractions
and ./externals because all of them contain "external objects" (as
explained in your other mail), then i don't see a reason to
introduce yet another directory that has to be migrated when the
time is nigh.in some other projects i noticed "packages" which are modules
containing both the local code plus dependencies (the latter handled solely
via svn:externals)Using svn:externals for dependencies means that using --ignore- externals would then break.
indeed it does!
the two things are unrelated; i was jus trying to add another
viewpoint (though i might have forgotten that i already mentioned
that). "packages" in this context meant small packages (e.g.
"libraries") rather than te entire shebang.Do you have an example of such a project? I am currently using OpenEmbedded a lot for the Reware ARM disk
images. OpenEmbedded tracks hundreds of external projects. It
uses git, which has nothing like svn:externals. Instead, the
build system, bitbake, which handles downloading the source code
to package. If we really want to make a distributed build system,
then someone should build it fromi do not oppose to explicitely downloading external dependencies at
all. via bitbat or whatever mechanism.bitbake or some other proven tool, not kludge it with svn:externals.
however to claim that "bitbake" is a 'proven tool' opposed to the
'ugly kludge' "svn:externals" is a bit euphemistic. unless of course you compare all the millions of openembedded
developers to the handful of people using subversion.
How many large integration projects are using svn:externals. That's
the real question. I've worked on a few, like WRT54G firmwares and
openembedded. The WRT stuff usually imports the code releases,
OpenEmbedded has a whole system of downloading the right versions
with automatic handling of mirrors.
but anyhow: what do we want to solve with all this "external" stuff
(be it pushed into the repo, pulled implicitly or pulled explicitly)? adding new "Pd-libraries" (1st level packages) or build- dependencies (2nd level packages). this 2 might well be handled differently.
I think it is a good idea to get rid of 'abstractions' and
'externals'. They should probably called 'libraries', or something
like that.
.hc
fgmsdr IOhannes
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie