Changes for autotools builds planned

[dmoore]

is it as simple as this?
http://ubuntuforums.org/showpost.php?p=2039057&postcount=16
(obviously someone needs to update for most recent changes)

[darthdespotism]

You can install Codeblocks like this but when you do this you will be unable to remove CB again vie apt

a simple way to additionally achive this is by installing checkinstall (I don't need to say how to install this right?) and typing sudo checkinstall instead of sudo make install.

Note that you need to change the version number so it doesn't contain any whitespaces any longer. You can do this in the interactive phase of checkinstall, it's quite simple.

A more complex way to build codeblocks is by typing sudo dpkg-buildpackage -uc -us (-b -nc) instead of make and make install and installing the generated *.deb(s).

dpkg-buildpackage doesn't work for me with the new autotools-setup but I hop it soon will. checkinstall and make install may or may not work with this update, you'll simply have to try and eventually check out a older debian/ directory meanwhile

[dmoore]

You can install Codeblocks like this but when you do this you will be unable to remove CB again vie apt

a simple way to additionally achive this is by installing checkinstall (I don't need to say how to install this right?) and typing sudo checkinstall instead of sudo make install.

he suggested the checkinstall command line in his post (at the bottom)

Note that you need to change the version number so it doesn't contain any whitespaces any longer. You can do this in the interactive phase of checkinstall, it's quite simple.

this is the sort of info I want in the wiki

A more complex way to build codeblocks is by typing sudo dpkg-buildpackage -uc -us (-b -nc) instead of make and make install and installing the generated *.deb(s).

dpkg-buildpackage doesn't work for me with the new autotools-setup but I hop it soon will. checkinstall and make install may or may not work with this update, you'll simply have to try and eventually check out a older debian/ directory meanwhile

I coudn't get dpkg-buildpackage to work on the old autotool-setup either, but that might be because is i didn't specify the correct options (i.e. "-uc -us" or "-b -nc"). again this is info that belongs in the wiki.

thanks for the tips

[darthdespotism]

without -uc -us dpkg will try to sign the package and as you don't have Mandrav's keys it will complain but did not stop building.

-b forces dpkg to only build a binary-Package and -nc prevents it from cleaning all the sourcetree. You probably want to clean it however (I don't do it because building everything takes considerably more time).

[cstudent]

I use dpkg-buildpackage all the time, so I don't know why it won't work for you. If you posted some error message, I might be able to tell you what is going on. I have a old tutorial on my website on how to build the packages, but it is a bit outdated. A person of some intelligence, which I'm sure you all qualify, should be able to use the info and apply to building a new package. One of these days I'm going to update it and include how I'm using pbuilder now to build the packages. pbuilder starts with a clean and lean os in a chroot environment and then forces you to get the depends right. Anyway, I use dpkg-buildpackage -D -S -us -uc -rfakeroot to create a .dsc file which I then use to run 'sudo pbuilder build nameoffile.dsc' to build the packages. I was able to build the new separate packages this way. However, I did make some tweaks to the control file under the debian folder. I changed the build depends section to use c++ 4.1, wx 2.8.4 and added libgtk2.0-dev.

[mandrav]

This is what I use to test the deb generation:

Code

fakeroot debian/rules binary

(this helps avoid lengthy recompile times)
(you obviously need to install the fakeroot package too)

[anarxia]

Just a few comments for the debian directory:
1. You basically hardcoded all dependencies. That's a big no-no for several reasons. You should use ${shlibs:Depends}.
    I can fix the packages to work correctly with ${shlibs:Depends} if you are interested and send a patch here.
2. The -devel prefix is -dev in the Debian/Ubuntu world.
3. You can build-depend on a specific version of libstdc++-dev, but you should also provide | libstdc++-dev as an alternative for people with
    other versions of g++.
4. You shouldn't install the .la files. All library packages remove those as they cause problems.

Thx for the comments. Patches are welcome

I uploaded the patch in the BerliOS site. (patch #002100).

[darthdespotism]

Not sure if it goes here right but the rev-Number should be upgraded in the changelog right?

Here it stays 4268 as is the Version in the Repos.

[mandrav]

Not sure if it goes here right but the rev-Number should be upgraded in the changelog right?

Here it stays 4268 as is the Version in the Repos.

It isn't updated automatically. You must run 'update-revision.sh' yourself (after 'svn update').

[darthdespotism]

ok thank you

[yop]

Now that I 'm also struggling with automake, adding a contrib plugin I have an idea on the generation of codeblocks packages. Instead of one codeblocks-contrib break it up in various codeblocks-contrib-<plugin name> and probably when the time comes to add it in a repository create a meta package named codeblocks-contrib that will install the "officially approved" plugins. It was a great help to use the existing automake structure you have for codeblocks to add another contrib but there is no point to creating a codeblocks-contrib including my plugin as the official one will not include it.

Oh and Yianni, in http://forums.codeblocks.org/index.php/topic,6428.msg49530.html#msg49530 you have a little typo that cost me  :lol:

[mandrav]

Now that I 'm also struggling with automake, adding a contrib plugin I have an idea on the generation of codeblocks packages. Instead of one codeblocks-contrib break it up in various codeblocks-contrib-<plugin name> and probably when the time comes to add it in a repository create a meta package named codeblocks-contrib that will install the "officially approved" plugins. It was a great help to use the existing automake structure you have for codeblocks to add another contrib but there is no point to creating a codeblocks-contrib including my plugin as the official one will not include it.

Yes, that's what's being planned for later. Separate package for each contrib plugin and a meta-package providing them all .

Oh and Yianni, in http://forums.codeblocks.org/index.php/topic,6428.msg49530.html#msg49530 you have a little typo that cost me  :lol:

Thx, corrected it .

[artoj]

I got whole bunch of errors when testing the generated packages using linda. The errors are mainly generated by the platform dependent files i.e. plugins in /usr/share/codeblocks/ directory.

EDIT: Could someone modify the line endings in "debian/control" file to LF only.