1. 3.2/4.0 build
Can someone build the executable files from the svn source and commit it into
the svn?
I tried to compile it but getting strange errors from watcom like the
incompatibility between exception and _exception etc and made me frustated.
I want the executable because I want to use peek2* and peek_string methods.
Thanks
2. Re: 3.2/4.0 build
yuku wrote:
>
> Can someone build the executable files from the svn source and commit it into
> the svn?
> I tried to compile it but getting strange errors from watcom like the
> incompatibility between exception and _exception etc and made me frustated.
> I want the executable because I want to use peek2* and peek_string methods.
Let's try not to commit the binaries to svn (except perhaps on release).
Better to put them up on sourceforge for download. If you're going to
be doing this, I recommend that you check out:
http://releaseforge.sourceforge.net
It makes the process pretty painless.
Matt
3. Re: 3.2/4.0 build
Matt Lewis wrote:
>
> Let's try not to commit the binaries to svn (except perhaps on release).
> Better to put them up on sourceforge for download. If you're going to
> be doing this, I recommend that you check out:
>
I wondered about that myself, but in SVN right now it contains libraries,
executables for Linux, Windows, DOS and FreeBSD.
Is that intended?
--
Jeremy Cowgar
http://jeremy.cowgar.com
4. Re: 3.2/4.0 build
Jeremy Cowgar wrote:
>
> Matt Lewis wrote:
> >
> > Let's try not to commit the binaries to svn (except perhaps on release).
> > Better to put them up on sourceforge for download. If you're going to
> > be doing this, I recommend that you check out:
> >
>
> I wondered about that myself, but in SVN right now it contains libraries,
> executables
> for Linux, Windows, DOS and FreeBSD.
>
> Is that intended?
Rob does that with each release. svn doesn't handle binaries very well, so
if we start committing binaries all the time, it's going to slow down
updates. Also, if we put it on SF, we get a download counter to give an
idea of how many people are using it.
Matt
5. Re: 3.2/4.0 build
Matt Lewis wrote:
>
>
> Rob does that with each release. svn doesn't handle binaries very well, so
> if we start committing binaries all the time, it's going to slow down
> updates. Also, if we put it on SF, we get a download counter to give an
> idea of how many people are using it.
>
Ok. I've just never seen that done before, adding the built binaries to SVN. I
wonder if after release they should be removed as it does cause confusion and
some difficulty with testing and maintaining SVN. For instance, I compile, build.
and want to do a good deal of testing, I copy the binaries from src/ and place
them in bin. Each time before svn commit, I have to remember to svn revert -R bin
--
Jeremy Cowgar
http://jeremy.cowgar.com
6. Re: 3.2/4.0 build
Jeremy Cowgar wrote:
>
> Matt Lewis wrote:
> >
> >
> > Rob does that with each release. svn doesn't handle binaries very well, so
> > if we start committing binaries all the time, it's going to slow down
> > updates. Also, if we put it on SF, we get a download counter to give an
> > idea of how many people are using it.
> >
>
> Ok. I've just never seen that done before, adding the built binaries to SVN.
> I wonder if after release they should be removed as it does cause confusion
> and some difficulty with testing and maintaining SVN. For instance, I compile,
> build. and want to do a good deal of testing, I copy the binaries from src/
> and place them in bin. Each time before svn commit, I have to remember to svn
> revert -R bin
I recommend not using your development tree as your installed version. The new
'nix install (only a deb package, so far) would pretty much enforce this.
Matt
