Changes for autotools builds planned

[mandrav]

There are a couple of changes planned for autotools-based builds. They 're already implemented and working here for me but I will not commit them just yet because I won't be available during this weekend and so I wouldn't be able fix anything that may go wrong.

• update-revision.sh will update the version-revision in the debian/changelog too so generated packages will have the correct name (in case you didn't know, update-revision.sh should be run after 'svn update' and before 'make clean-zipfiles').
  
  
• The configure option '--enable-contrib=[yes|no]' is now obsolete. It has been replaced by the '--with-contrib=[all | plugin names separated with comma]'. So now you have the chance to avoid building contrib plugins you never use.
  
  
• Building the debian packages will no longer generate a single codeblocks*.deb package. Instead, 4 packages will be generated: codeblocks (main package), codeblocks-contrib (contrib plugins), codeblocks-dbg (unstripped binaries of codeblocks for debugging) and codeblocks-devel (sdk headers and libraries).
  

That's about it. These changes will probably be committed on coming Monday.

[Biplab]

Thanks a lot for the update.

Waiting for the commit.

[mandrav]

Seeing no comments, I guess there are no objections .

Another thing I 'd like feedback on is this: should one codeblocks-contrib package be created or one package per contrib-plugin? What do you think?

[PsYhLo]

put POLL and will see
i'm for one codeblocks-contrib

[raph]

I'm for one codeblocks-contrib package, too.

[mandrav]

Changes committed.

--enable-contrib option has been replaced by --with-contrib-plugins=[all|comma-sep. plugin names].

Generated packages are:

• libcodeblocks0
• codeblocks
• codeblocks-contrib
• codeblocks-dbg
• codeblocks-devel
• libwxsmithlib0
• libwxsmithlib0-devel

lintian has 0 (zero) complaints about the packages :).

[dmoore]

Mandrav: is there a wiki entry explaining how to use these things correctly? (even just command lines and required packages for deb/rpm systems)

[darthdespotism]

It seems this update has broken the build on my box

Code

dpkg-buildpackage: source package is codeblocks
dpkg-buildpackage: source version is 1.0svn4266
dpkg-buildpackage: source changed by Yiannis Mandravellos <mandrav@codeblocks.org>
dpkg-buildpackage: host architecture i386
dpkg-buildpackage: source version without epoch 1.0svn4266
dpkg-checkbuilddeps: Unmet build dependencies: libstdc++6-4.0-dev
dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.

libstdc++6-4.1 is installed on my box / Ubuntu7.04

And another one after modifying the control to point to 6-4.1

Code

dh_installexamples
dh_install --fail-missing --sourcedir=debian/tmp
cp: Aufruf von stat für „debian/tmp/usr/lib/libcodeblocks.so.0“ nicht möglich: No such file or directory
dh_install: command returned error code 256
make: *** [binary-arch] Fehler 1

[cstudent]

I was able to successfully build the packages under Ubuntu Edgy using pbuilder and install & run it in Fiesty. I made a couple of tweaks. I changed wx to version 2.8 and I had to add libgtk2.0-dev to build depends. What we need now is a repository that one could add and get automatic updates of the packages.

[rjmyst3]

What we need now is a repository that one could add and get automatic updates of the packages.

That would be great 

[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.

[mandrav]

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

[mandrav]

Mandrav: is there a wiki entry explaining how to use these things correctly? (even just command lines and required packages for deb/rpm systems)

These are the generated packages (if one would build them). For installing them, use your distro's package manager(e.g. synaptic, dpkg, etc).
Also, there are dependencies between them so you can't, for example, install the 'codeblocks' package without first installing 'libcodeblocks0'. Your package manager would either install the dependencies automatically or, at the worst case scenario, tell you about what's missing.
Finally, the -dev(el) packages are only needed if you want to use the C::B SDK (w/out having C::B in source form available).

[Charon]

that looks quite nice

personally i think i would split the contrib plugins up into a few packages, but create a meta-package which references all of them.

the dev-package is a great idea btw!

greets
Markus

[dmoore]

These are the generated packages (if one would build them)

yes, I want info on building the packages correctly (as opposed to installing them). I asked about dependencies because I assume that to build the packages there are several tools required (such as debhelper). I never did manage to create the deb package with the old setup and I figure I'm not the only person who would be interested in having this info in a readily accessible place