On Fri, 2007-04-27 at 15:15 -0400, Peter Amstutz wrote:
> Uh, I don't think giving everybody accounts on baikonur (the
> interreality.org server) is going to solve much. For one thing, it only
> runs Debian, and a big part of the discussion here is how best to
> support building on Windows and
Uh, I don't think giving everybody accounts on baikonur (the
interreality.org server) is going to solve much. For one thing, it only
runs Debian, and a big part of the discussion here is how best to
support building on Windows and OS X.
We intend to do 3rd party world hosting at some point in
On Wed, 25 Apr 2007 23:07:11 -0400, Peter Amstutz wrote:
> It's actually "make distcheck" that's interesting in this case.
Ok, but the first step to get there is to replicate "make dist" :-)
> Also
> "make dist" is distinguished from simply dumping your repository to a
> tar file by the fact that
On Thu, 2007-04-26 at 09:21 -0400, Reed Hedges wrote:
> On Wed, Apr 25, 2007 at 11:07:11PM -0400, Peter Amstutz wrote:
> > [1] Although there is a case to be made that such files should be
> > included in your repository anyway, since there are people who might
> > want to check out the latest so
On Wed, Apr 25, 2007 at 11:07:11PM -0400, Peter Amstutz wrote:
> It's actually "make distcheck" that's interesting in this case. In
> automake it gives you a single command that will build a source tarball,
> unpack it to another directory, runs configure and does a build. It's a
> very useful
It's actually "make distcheck" that's interesting in this case. In
automake it gives you a single command that will build a source tarball,
unpack it to another directory, runs configure and does a build. It's a
very useful automated sanity check on your source distribution. Also
"make dist"
I realise this is probably not the biggest con of scons (I guess that would be
the slowness), but I'd be happy to write a "make dist" alike command and
contribute it to upstream scons. I wrote the similar thing for bzr, after all.
best,
Lalo Martins
As brought up earlier, I'm unhappy with the current automake build
system used in VOS due to maintainance overhead (even trivial modules
have grown to require a dozen lines of boilerplate) and the considerable
difficulty it poses to properly supporting Windows development. We
resolved the last
