Sorry, I am very slammed right now, so I didn't have time to look at this build issue. I moved everything to point to the Gem SVN now, so it should work fine.
Instead of svn:externals, another option is to import gem releases into the pure-data SVN. I am working a lot now with openembedded, and basically all the code used there is pegged to a certain release version. With big distros like Pd-extended, that is necessary in order to get anything released. I suppose it would also be possible then to have a Gem-only nightly build.
Moving gem development to the pure-data SVN would also solve this issue, so there are many ways to do it. If someone wants to run a build farm and maintain Pd-extended, I'll happily defer to them on these questions. But right now, for me, svn:externals solves no problems and also creates new problems.
.hc
On Aug 27, 2008, at 9:30 PM, zmoelnig@iem.at wrote:
some of the autobuilds have been failing for ages now, because of a change introduced into Gem's directory layout, the autobuild system's adaption to it and some somewhat out-of-sync autobuild hosts.
Subject: [PD-cvs] autobuild: pd-main+libs debian-testing-i386 Subject: [PD-cvs] autobuild: pd-puredyne debian-testing-i386 Subject: [PD-cvs] autobuild: pd-main+libs ubuntu-hardy-i386 2008-08-26
all of these are failing, because of the following history:
- Gem has switched form CVS to SVN
- the autobuild system (or rather: the human that is behind that:
hans) has tracked Gem's switch to svn
- i have tidied up Gem a bit and moved the "manual/" into the
"doc/" section
- hans has adapted the autobuild system accordingly
- somehow some machines got out of sync: they have updated their
autobuild system to include the change in the directory layout, but are still using the CVS version of Gem (where this change has not yet occured)
- these machines fail to build each night
i think it is related to the re-occuring (e.g. see the current thread on flext-svn) discussion of svn:externals
as i can see it, there are 2 main arguments against svn:externals
- (fear of) problems when doing "svn update" (e.g. due to unofficial
certificates)
- (fear of) problems when re-structuring the repository (e.g. when
importing code that was previously integrated via svn:externals)
as can be seen by the example above, also the alternative approach (using scripts to explicitely checkout a remote repository) is not foolproof (well nothing is), and actually exhibits the very problems because of which it is used (apart from legacy reasons for sticking to them)
mfg.dsr IOhannes
This message was sent using IMP, the Internet Messaging Program.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White