Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

autorevision incompatible with portage's build process

(1/2) > >>

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.


--- Quote from: thomas on May 09, 2006, 07:13:30 pm ---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.

--- End quote ---
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.


--- Quote from: thomas on May 09, 2006, 07:13:30 pm ---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.

--- End quote ---
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.


--- Quote from: thomas on May 09, 2006, 07:13:30 pm ---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.
--- End quote ---
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:

--- Quote from: daniel2000 on May 09, 2006, 07:52:00 pm ---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 ;)

--- End quote ---
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

Navigation

[0] Message Index

[#] Next page