error when compiling from svn sources (25-10/2006)

[thomas]

my svn is 1.3.0, but I get errors instead of warnings.

I thought svn 1.4.0 was required now ?

All that matters is what a man can do, and what a man can't do.

For instance, you can:
- check out with Subversion 1.4 and have svn in PATH
- check out with Subversion 1.4 and not have svn available
- check out with Subversion 1.0, 1.1, 1.2, or 1.3 and have svn in PATH

What you cannot do is:
- check out using 1.3 and not have svn in PATH
- check out using 1.4 and have svn 1.3 in PATH
- check out using 1.3, update using 1.4, then change your mind and expect things still to work

Are you man enough to sail under a pirate's flag then? 

[afb]

Are you man enough to sail under a pirate's flag then? 

I use CVS :-P

But I guess checking out with /opt/local/bin/svn was a bad idea.
When I have to compile SVN, then I might as well go for 1.4.0...

[ddd]

Interesting... I even considered using LANG=jwsdhadgh or LANG=none for a while, since gettext should fall back to whatever is built-in if it can't find it (which is the desired effect). :lol:
But then, LANG=EN looked a lot nicer, so I stuck with that. Interestingly, it does not produce any kind of warning under Windows

I did not choose any kind of subset such as en_US because I wasn't sure which one to take  (US citizens will probably claim that en_US is without doubt the "original thing", but UK residents will not necessarily agree that this is English at all). I don't know which one is the native one. Maybe en_US and en_UK (or en_AU) are even the same for Subversion by coincidence. But honestly, I actually don't want to bother

What we need is one format that's always the same, preferrably the one that's built into the Subversion binary, so it will run on every target PC. My proposal is that you try whatever doesn't give you errors, and we'll stick with that for now (until someone else complains).

Isn't it possible to unset the variable instead? Wouldn't that produce the output that is built inside svn?
I tried both unsetting the variable and setting it to empty, and I got english text output. (I'm using Ubuntu Linux)

[Game_Ender]

Eventually, at some point in the future, I will rewrite autorevision to parse Subversion's xml output, which will once and for all end this sad story.
However, since most people still use 1.3 (which only supports that option for a small subset of commands) and some even 1.2 (which doesn't support it at all), this is currently probably not such a good idea.

The subversion developers don't recommend parsing the output of the subversion command lines tools.  That's why your job is so hard.  Have you considered using the libraries they provide instead?

[thomas]

The subversion developers don't recommend parsing the output of the subversion command lines tools.  That's why your job is so hard.  Have you considered using the libraries they provide instead?

Alas, poor Yorick! I knew him, Horatio: a fellow of infinite jest, of most excellent fancy...

That question should get you the best-computer-joke-of-the-year award

As this is the first obvious thing to try for a Subversion plugin (rather than launch an external tool that is not found / the wrong version / slow / error-prone), I certainly tried before.
The libraries they provide neither work with MinGW, nor does it seem feasible to convert them. Compiling Subversion from source is a story of its own...
The first dependency is Neon. Get back to me when you have managed to compile Neon with MinGW

[afb]

The subversion developers don't recommend parsing the output of the subversion command lines tools.

Subversion has been affected by the same disease as Yum then...
It even changes the output on purpose, to defeat screenscraping.

My sympathies to you, Thomas. Seems like an awful amount of
work just to get a single revision number in the about box... :-)

[tiwag]

why not providing a svn executable in the svn repository ?
then you always could use "svn info" and parse the revision number from there ?

[thomas]

Subversion has been affected by the same disease as Yum then...
It even changes the output on purpose, to defeat screenscraping.

My sympathies to you, Thomas. Seems like an awful amount of
work just to get a single revision number in the about box... :-)

The funny thing is that the "official correct way" to do that is to run svn in backticks from the makefile and pipe the output through sed. We'd probably do that if we were building Code::Blocks with makefiles everywhere. But even then it would be a pain, as it would have the very same issues.
So we're rather using one tool everywhere instead of two solutions for two build systems, both of which don't work reliably  :lol:

[thomas]

why not providing a svn executable in the svn repository ?
then you always could use "svn info" and parse the revision number from there ?

Distributing executables for being able to build from source is giving me the creeps...

Apart from that, we would need at least 3 executables (Windows, Linux/BSD, Mac) to cover the four most used platforms. Actually twice as many, if you account for 32/64 bits and Intel/PPC...

Also, we would still have potential issues then. If we distribute Subversion 1.3, but someone used 1.4 to check out, it won't work. On the other hand, if we distribute 1.4 and the working copy is 1.3, it might possibly break the working copy for the user by updating the repo. I don't think that will actually happen on svn info, but I haven't tried!
Regardless of whether it works now, it could be the same issue again with version 1.5, 1.8, or 2.0 any time in the future.

[tiwag]

linux and mac should always have svn commandline client installed, isn't it?
this should be true for every serious developer on windoze too 

Although it doesn't interest me what gives you the creeps,
i would simply use svn, and everyone who wants to build his own C::B from svn has to install it - basta

[afb]

I don't think requiring Subversion for compiling the nightly build
is any harder of a requirement than requiring wxWidgets installed...
The language/locale issue was a curveball, but seems sorted out.

Maybe you could also take a look at the proposed autorevision changes ?
I would like to have access to the raw rev. number, without the trunk-

Code

m4_define([SVN_REVISION], trunk-r3163)
m4_define([SVN_REV], 3163)

Code

--- configure.in        (revision 3163)
+++ configure.in        (arbetskopia)
@@ -49,6 +49,8 @@
 AC_CHECK_FUNC(snprintf, AC_DEFINE(HAVE_SNPRINTF,,snprintf))
 AC_CHECK_FUNC(vsnprintf, AC_DEFINE(HAVE_VSNPRINTF,,vsnprintf))
 
+AC_SUBST(REVISION, SVN_REV)
+
 dnl versioning info for libtool
 dnl Note this is the ABI version which is not the same as our actual library version
 CODEBLOCKS_CURRENT=0

The RPM spec is using a sed hack, but that doesn't work too good for XML...
(I want it to be able to autogenerate a codeblocks.plist, for Mac OS X)

Code

--- codeblocks.spec.in  (revision 3163)
+++ codeblocks.spec.in  (arbetskopia)
@@ -1,4 +1,4 @@
-%define _svnrev                %(echo @VERSION@ | cut -c 8-)
+%define _svnrev                @REVISION@
 %define req_wxgtk      2.6.0
 %define _fedora                %(if [ -f /etc/fedora-release ]; then echo 1; else echo 0; fi)
 %define _suse           %(if [ -f /etc/SuSE-release ]; then echo 1; else echo 0; fi)

edit: on second thought, changing SVN_REVISION is probably a little confusing.
Not to mention that the variable and define having the same name doesn't work.

[afb]

linux and mac should always have svn commandline client installed, isn't it?

True for the latest versions, not so for older versions (it is installable...)

[thomas]

linux and mac should always have svn commandline client installed, isn't it?

This is why we are having these troubles... those are all localised.

Although it doesn't interest me what gives you the creeps, i would simply use svn, and everyone who wants to build his own C::B from svn has to install it - basta

When I first incepted autorevision, it only worked with Subversion, had no fallback, and did not do any serious error checking.
The same day (because he promptly encountered a problem), Yiannis came up with the following requirements:
1. it must not break the build
2. it must work with an exported tarball, i.e. when there is no revision information at all
3. it should work without svn or any other dependencies, having a fallback
4. it can have revision=0 as fallback if nothing else helps

Maybe you could also take a look at the proposed autorevision changes ?
I would like to have access to the raw rev. number, without the trunk-

But... that's exacly what autorevision provides? The trunk- comes from somewhere else...?

<everything else>

(pretends to understand anything you said)
Yes... that looks nice, dear.   :lol:

[Game_Ender]

I am going to have to give this a try because last time on checked, C libraries were complier independent thanks to the standard C abi.  I will see how the subversion developers managed to subvert this.

[afb]

When I first incepted autorevision, it only worked with Subversion, had no fallback, and did not do any serious error checking.
The same day (because he promptly encountered a problem), Yiannis came up with the following requirements:
1. it must not break the build
2. it must work with an exported tarball, i.e. when there is no revision information at all
3. it should work without svn or any other dependencies, having a fallback
4. it can have revision=0 as fallback if nothing else helps

Yeah, I guess we do need some kind of such workaround for Windows...
(I saw that someone was working on a replacement for wx-config too)

But... that's exacly what autorevision provides? The trunk- comes from somewhere else...?

<everything else>

(pretends to understand anything you said)
Yes... that looks nice, dear.   :lol:

Sorry, I was mixing up autorevision with update_revision.sh -
I meant "revision" handling in general, sorry for the confusion...

Autorevision only writes the src/sdk/autorevision.h header, right ?
Will do up a proper patch for the other change, to the autoconf.