A problem about C::B svn make(Ubuntu12.04)

[cacb]

Well, I have made some progress. I've moved to another computer with a fresh Kubuntu 13.04 64bit, and it does indeed work to follow the dpkg-buildpackage route

Some observations
- I thought I would get the very latest nightly build code from trunk http://svn.code.sf.net/p/codeblocks/code/trunk/ , however it seems to be some old 10.05 version. Instead I downloaded from http://svn.code.sf.net/p/codeblocks/code/branches/release-12.11/. Where are the latest updates?
- On the new machine, I built against the distro's own wx2.8.12, which worked. Not sure what will happen after I build my own version of wxWidgets like I normally do, and then try to rebuild codeblocks
- Had issues with an NTFS partition, could not build code::blocks on that until I had to properly mounted, Unrelated to C::B, but it is an issue sometimes with dual boot machines.

The IDE is up and running, while at the same time the latest updates have broken the previous ones I got from Jens. So I guess it is time for a major overhaul of my setups.

[oBFusCATed]

Where are the latest updates?

Here: http://svn.code.sf.net/p/codeblocks/code/trunk/ probably something is broken in the debian files.
Do you get a proper archive using the following commands:

Code

./bootstrap
./configure
make dist

You should get codeblocks-12.11*.tar.bz file.

[Jenna]

You should run ./bootstrap before any automake command to update the Makefile's and the debian/changelog .
The revision of the debian files is taken from the debian/changelog if you use dpkg-buildpackage.

What does svn info say about the revision ?

[cacb]

You should run ./bootstrap before any automake command to update the Makefile's and the debian/changelog .
The revision of the debian files is taken from the debian/changelog if you use dpkg-buildpackage.

ok, does this mean a ./bootstrap  is required before sudo dpkg-buildpackage command? I didn't know, these tools are new to me. Essentialy I need to understand exactly which steps to take to download the latest svn code, build deb packages that I can use on my identically configured Kubuntu machines.

What does svn info say about the revision ?

Don't know, because I use bazaar with bzr-svn to download the code    But I used bzr qlog and saw that indeed the latest update was just a few days old. I have deleted it already as I thought it was a mistake since it gave me the 10.05 packages. But if it really was just a question of running ./bootstrap, I can try again.

[Jenna]

./bootstrap creates the uptodate Makefile.in's and updates the revision.
At least in theory.
In your case it will not do so, because you use neither svn, git-svn nor git, but only these three scm-clients are supported by the underlying scripts.

You can look at the shell-script update_revision.sh and probaly tweak it to work with bzr-svn, but your on your own here, because no one of our dev's uses bazaar as far as I know.

What you can do manually is the following:

• run ./bootstrap to create the correct Makefile.in's,
• create a file named revision.m4 in the sources root,
• put

  m4_define([SVN_REV], 9099)
  m4_define([SVN_REVISION], 12.11svn9099)
  m4_define([SVN_DATEinto it], 2013-05-16 18:22:06)

  into it
• use your svn-revision and -date, of course
• run

  dch -v 12.11svn9099 "New svn revision"
• use your svn-revision again
• run dpkg-buildpackage

Or just don't use our svn-repo, but the sources from my server:
http://apt.jenslody.de/testing/pool/main/c/codeblocks/

If you just download the *.orig.tar.gz tar-ball, you get the pure svn-sources without any patches, but after running ./bootstrap.
Ready for use with dpkg-buildpackage.
I update my repo much more frequently as this happens for the windows nightlies (currently I have svn r9099).

[cacb]

Or just don't use our svn-repo, but the sources from my server:
http://apt.jenslody.de/testing/pool/main/c/codeblocks/

If you just download the *.orig.tar.gz tar-ball, you get the pure svn-sources without any patches, but after running ./bootstrap.
Ready for use with dpkg-buildpackage.
I update my repo much more frequently as this happens for the windows nightlies (currently I have svn r9099).

Thank you, jens. I didn't know there was a dependency between the scm client and the build system. That's a bit unfortunate. I shall have a look at those scripts, but downloading the *.orig.tar.gz post ./bootstrap tar-ball from your server, ready for or use with dpkg-buildpackage seems to be the easiest by far. Probably the download is much faster that way too.

[Jenna]

I didn't know there was a dependency between the scm client and the build system. That's a bit unfortunate.

The build-system needs to know the svn-revision (at least for svn-builds, release builds are another story) and the only reliable way to get it, is to fetch the revision with the scm-client.

[cacb]

Thanks again, I managed to build it properly from svn trunk, code fetched with bzr-svn with ./bootstrap + the manual steps you described in reply#19. The only issue I had was my local static wxWidgets build got in the way, causing the C::B dpkg-buildpackage to fail after some time. I solved that by "hiding" my local wx-config and "unhiding" after the dpkg-buildpackage, not sure if there is any smarter way but it worked

Code

sudo mv /usr/local/bin/wx-config  /usr/local/bin/wx-config-hide 
sudo dpkg-buildpackage
sudo mv /usr/local/bin/wx-config-hide /usr/local/bin/wx-config

svn 9099 looks quite nice!

[Jenna]

Run ./configure--help and you see the option --with-wx-config=CONFIG .
Add it (with path to correct wx-config) to DEB_CONFIGURE_EXTRA_FLAGS in debian/rules and it should work.

[cacb]

Run ./configure--help and you see the option --with-wx-config=CONFIG .
Add it (with path to correct wx-config) to DEB_CONFIGURE_EXTRA_FLAGS in debian/rules and it should work.

Thanks yet again. I have tried this on another Kubuntu 13.04 (32bit this time) and successfully built the C::B debs from the tarball on your site. The way to configure which wx-config to use reminds me of a similar problem when using C::B and trying to tell C::B/compiler to find the correct wx-config during compilation. I have a compiler setting (other options) like this

Code

`/usr/local/bin/wx-config --version=2.8 --toolkit=gtk2 --cxxflags`

As far as I know, hardcoding this way is the only way to select the correct wx-config within C::B. I would have liked to use a global variable, but at least in the past such variables didn't expand within backticks. Is there a smarter way now? Something similar to --with-wx-config=CONFIG  with global variables would be nice to have. Or simply expand global variables also within backtick strings.

Finally, once the C::B debs have been built, they must be installed in the correct order. By trial and error I found that this worked (32bit version)

Code

sudo dpkg -i codeblocks-common_12.11svn9099_all.deb
sudo dpkg -i libcodeblocks0_12.11svn9099_i386.deb
sudo dpkg -i libwxsmithlib0_12.11svn9099_i386.deb
sudo dpkg -i codeblocks_12.11svn9099_i386.deb 
sudo dpkg -i codeblocks-contrib-common_12.11svn9099_all.deb
sudo dpkg -i codeblocks-libwxcontrib0_12.11svn9099_i386.deb 
sudo dpkg -i codeblocks-contrib_12.11svn9099_i386.deb

Is there some easier way to simply say "install all and resolve dependencies between them" (without using a repository)?