autorevision incompatible with portage's build process

[me22]

( I just noticed this trying to build 2438, but based on svn blame I expect it's been like this since 2374 or 2375 )

src/tools/autorevision/Makefile.am includes the following line:
./auto_revision +int +wx +t $(top_srcdir) $(srcdir)/../../sdk/autorevision.h

The program then uses $(top_srcdir) to look at the svn info for that directory to determine the revision of the code it's using (I'm assuming), but because portage copies the checked-out source tree, the .svn folder isn't there.

Are there any files with the revision information header that could be looked at instead? `grep '\$Revision' -R . | grep -v '\.svn'` mentions a bunch of candidates, but that's the last revision of the file, not the revision of the checkout.  Maybe a different $tag$?

I'll code up the changes for autorevision if someone can tell me where I can parse the information from.

[thomas]

autorevision runs the command svn info to determine the revision information. Only if that fails, the file .svn/entries is parsed as a fallback.
This is a (unluckily not well-formed) xml file. Since tinyXML refuses to parse that file, I did a very simple string search, which is not  nice but works out nevertheless.

What you need is some entry file from some .svn directory (they should all have the same last-commit number). In the cbp, I used "." as the path, the makefile (which I did not write) uses "../.." for some reason, but it does the exact same thing (because the last-commit revisions are the same everywhere).
So actually you don't need to change one single line of code, only provide the correct path to some place where a .svn directory is found on the commandline.

I know of no other way to reliably determine the revision information. One could of course query the current HEAD revision directly from the repository via svn:// quite trivially, but that would
a) not guarantee that the revision on disk is the same as in the repository
b) cause the build to depend on the availability of the BerliOS server (i.e. if that server is down, nobody can compile)
Especially b) is prohibitive.

[me22]

Wow, thanks for the incredibly quick response.

autorevision runs the command svn info to determine the revision information. Only if that fails, the file .svn/entries is parsed as a fallback.
This is a (unluckily not well-formed) xml file. Since tinyXML refuses to parse that file, I did a very simple string search, which is not  nice but works out nevertheless.

Well, svn info would be looking in the .svn directory for the info, so either way it's not there if portage hasn't copied the .svn folder.

What you need is some entry file from some .svn directory (they should all have the same last-commit number). In the cbp, I used "." as the path, the makefile (which I did not write) uses "../.." for some reason, but it does the exact same thing (because the last-commit revisions are the same everywhere).
So actually you don't need to change one single line of code, only provide the correct path to some place where a .svn directory is found on the commandline.

That's actually the workaround I'm using at the moment to compile it.  I changed the Makefile.am from
./auto_revision +int +wx +t $(top_srcdir) $(srcdir)/../../sdk/autorevision.h
to
./auto_revision +int +wx +t /usr/portage/distfiles/svn-src/codeblocks/trunk/src/ $(srcdir)/../../sdk/autorevision.h
at which point it works fine, but that's obviously not an acceptably generic solution either.

Could there perhaps be a new variable added?  Then the Makefile.am could use $(top_checkoutdir) or something which would default to $(top_srcdir) but that I could set by passing the configure script the value?  Unfortunatly I don't know enough about auto* to know how to do that.

I know of no other way to reliably determine the revision information. One could of course query the current HEAD revision directly from the repository via svn:// quite trivially, but that would
a) not guarantee that the revision on disk is the same as in the repository
b) cause the build to depend on the availability of the BerliOS server (i.e. if that server is down, nobody can compile)
Especially b) is prohibitive.

Agreed, that's not an acceptable solution. (a) is also prohibative, because it would wreak havok on bug reports.

[TheTuxKeeper]

moloh submitted a new ebuild which also downloads the .svn directories (last post in the mentioned Gentoo Bugzilla link): http://forums.codeblocks.org/index.php?topic=3010.msg24202#msg24202

[me22]

moloh submitted a new ebuild which also downloads the .svn directories (last post in the mentioned Gentoo Bugzilla link): http://forums.codeblocks.org/index.php?topic=3010.msg24202#msg24202

Excellent, thanks.

His rsync method is a particularly elegant way too, nice.

[edit]
Well, I tried his eBuild, and now r2438 fails to build quite quickly.
It wont let me paste the log in here, so I've put it on http://pastebin.ca/54586

[Der Meister]

From your log I can see that it uses wxGTK-2.4 to compile. But this won't work as Code::Blocks needs at least wxGTK-2.6. Although the ebuild states wxGTK-2.6.2 as dependency it looks like it uses 'wx-config' when calling ./configure. But (at least on gentoo) wx-config is for wxGTK-2.4! Thus configure should use 'wx-config-2.6'. Thus the call to econf should look like this:

Code

econf --with-wx-config=wx-config-2.6 ${myconf} || die "econf failed"

Anyone able to submit this change as new ebuild?

[tiger683]

The wxGTK version problem has been solved in my gentoo overlay since quite some time now,
and the autorevision problem can be solved with a simple one-line sed command

Look here: http://forums.gentoo.org/viewtopic-t-440412.html

But just to make you know, i'm testing new revision of the overlay right now before i update that topic,
since the build fails now on patching the wxFlatNotebook since it got commited into svn recently.
But all in all it works if you simply remove the patch from files/patches subdirectory and redigest,
and after all it will get updated in about an hour including 2.7.0-svn version of angelscript for amd64 scripting
support....

Thanks,

T

EDIT:
Just for convenience:

Code

# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

inherit autotools wxwidgets subversion
ESVN_CO_DIR="${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}"/svn-src/${P/-svn}/"${ESVN_REPO_URI##*/}"

ESVN_REPO_URI="svn://svn.berlios.de/codeblocks/trunk"
ESVN_PROJECT="${P}"

WX_GTK_VER="2.6"

DESCRIPTION="free cross-platform C/C++ IDE"
HOMEPAGE="http://www.codeblocks.org/"
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~x86 ~amd64"

IUSE="contrib unicode xrc monolithic debug"

RDEPEND="=x11-libs/wxGTK-2.6*
	x11-libs/gtk+
	!dev-util/codeblocks
	!dev-util/codeblocks-cvs"

DEPEND="${RDEPEND}
	>=sys-devel/autoconf-2.5.0
	>=sys-devel/automake-1.7
	>=sys-devel/libtool-1.4
	app-arch/zip"

pkg_setup() {
	if use unicode; then
		need-wxwidgets "unicode"
	else
		need-wxwidgets "gtk2"
	fi
}

src_unpack() {
	subversion_src_unpack
	
	EPATCH_SOURCE="${FILESDIR}/patches" \
	EPATCH_SUFFIX="patch" \
	EPATCH_ARCH="all" \
	epatch
	sed -i -e "s:\$(top_srcdir):${ESVN_CO_DIR}:" src/tools/autorevision/Makefile.am
}

src_compile() {
	cd ${S}

	eautoreconf || die "Died in action: eautoreconf..."

	einfo "Changing properties ..." && \
	edos2unix ${S}/{bootstrap,src/update} && \
	chmod a+rx ${S}/{bootstrap,src/update} && \
	edos2unix ${S}/src/setup/mime/codeblocks.{desktop,applications} || \
	die "Died in action: properties ..."

	./bootstrap || die "Died in action: shipped bootstrap ..."

	econf --with-wx-config=wx-config-2.6 --enable-dependency-tracking \
	$(use_enable contrib) $(use_enable unicode) $(use_enable xrc) \
	$(use_enable monolithic) $(use_enable debug) \
	|| die "Died in action: econf ..."
	make clean-zipfiles || die "\"make clean-zipfiles\" failed..."
	make || die "Died in action: make ..."
}

src_install() {
	make DESTDIR="${D}" install || die "Died in action: make install ... "
}

[mandrav]

including 2.7.0-svn version of angelscript for amd64 scripting support....

Huh?
There is no 2.7.0-svn. The svn version is what 2.6.+ will become, AFAIK.
Besides, where did you see the 64bit support? AS supports 64bits in AS_MAX_PORTABILITY mode only...

[tiger683]

including 2.7.0-svn version of angelscript for amd64 scripting support....

Huh?
There is no 2.7.0-svn. The svn version is what 2.6.+ will become, AFAIK.
Besides, where did you see the 64bit support? AS supports 64bits in AS_MAX_PORTABILITY mode only...

Well, then the code in there is a little confusing:

Code

--- codeblocks-9999-orig/src/sdk/as/include/angelscript.h	2006-05-10 19:27:47.000000000 +0200
+++ codeblocks-9999/src/sdk/as/include/angelscript.h	2006-05-10 19:32:09.372021000 +0200
@@ -53,11 +53,11 @@ BEGIN_AS_NAMESPACE
 
 // AngelScript version
 
-#define ANGELSCRIPT_VERSION        20601
+#define ANGELSCRIPT_VERSION        20700
 #define ANGELSCRIPT_VERSION_MAJOR  2
-#define ANGELSCRIPT_VERSION_MINOR  6
-#define ANGELSCRIPT_VERSION_BUILD  1
-#define ANGELSCRIPT_VERSION_STRING "2.6.1 WIP"
+#define ANGELSCRIPT_VERSION_MINOR  7
+#define ANGELSCRIPT_VERSION_BUILD  0
+#define ANGELSCRIPT_VERSION_STRING "2.7.0 WIP"
 
 // Data types
 
@@ -187,10 +187,10 @@ extern "C"

Just a snipp of an update patch from 20060505 svn to today's. (EDIT: attached the full patch against c::b-svn)

About the 64bit support I didn't really know, although the comments of preliminary 64bit support are
on the HP, I probably missed the details..... I'm not a 64bit user, so i couldn't verify anyway....

Thanks,

T


[attachment deleted by admin]

[moloh]

From your log I can see that it uses wxGTK-2.4 to compile. But this won't work as Code::Blocks needs at least wxGTK-2.6. Although the ebuild states wxGTK-2.6.2 as dependency it looks like it uses 'wx-config' when calling ./configure. But (at least on gentoo) wx-config is for wxGTK-2.4! Thus configure should use 'wx-config-2.6'. Thus the call to econf should look like this:

Code

econf --with-wx-config=wx-config-2.6 ${myconf} || die "econf failed"

Anyone able to submit this change as new ebuild?

DONE.
Ebuild in gentoo bugzilla is "pure", no patches, only svn checkout and compile...