remove automake

[r00t-]

vzlogger used to have a build setup for both autotools and cmake.
it doesn't look like we're going to maintain both of them.
this removes the autotools setup. (and some other stale files).
(i' only 99% sure i removed all the right files)

[justinotherguy]

I don't agree on this (yet); generating the .deb package (using "dpkg-buildpackage -b") triggers automake, too. Debian packages can also be generate with cmake (cpack -G DEB), but at present:

• they do not contain the scripts and config files for vzlogger, only the binary itself
• they contain an unstripped binary of vzlogger

For the moment I'd therefore prefer fixing automake; once we know how to get proper debian packages with "cpack -G DEB", I don't mind abandoning automake.

[r00t-]

the debug-build is INTENTIONAL, see #66
(one might include a stripped and a -debug version in the package)

the automake build is already broken by recent changes, and lot of work to fix.

why can't we simple have the debian build setup run cmake instead of configure?
the setup in debian/ is not part of automake, it only invokes automake (as it is set up currently)!

[r00t-]

applying this gets pretty close already:
(it runs cmake successfully, but then the wrong make command for some reason)
(not going to commit this into the branch, because then it will be demanded i do everything all over again and make a new pull request because this one isn't beautiful enough anymore)

debian/rules:
-%:
-       dh $@ 
+include /usr/share/cdbs/1/rules/debhelper.mk
+include /usr/share/cdbs/1/class/cmake.mk

debian/control:
Build-Depends: .... +, cdbs

(note how the repostory-urls in debian/control are rather ancient and outdated...)

[r00t-]

from what i read, "cpack -G DEB" creates kind of a bare-bones very basic .deb package
(lacking the option to add advanced features),
and we'd want to continue using the debian build system anyway, to get a full-featured package.

[andig]

Why do we need packages at all after 2 years without?

[justinotherguy]

The latest debian package dates from Oct. 13 - the question is still valid, though.
The question is:
how do the users of vzlogger update their installation? I see these options:

• download a new RPi image (1.3G) and migrate their data (...)
• stick to their RPi image and fiddle with git and cmake
  I'm aware that not all users of vzlogger run a RPi, but I think the debian packages are a method for providing especially new users and those with little background with updated versions of vzlogger.
  See also my posting on vz-users: https://demo.volkszaehler.org/pipermail/volkszaehler-users/2015-January/005339.html
  Personally I appreciate the comfort of having an updated system for many packages - I don't see why we shouldn't try that for vzlogger as well.

[justinotherguy]

r00t: I'm more than ok if we manage to integrate cmake into dpkg-buildpackage! :-)
Thanks for pointing out that the debug option was enabled intentionally - I remember the discussion, but I had forgotten about it.

[r00t-]

note that the "raspberry pi image" already contains the whole build setup,
including a clone of the github repository (iirc).
so a package is not really needed for upgrading there.

(also, there is lots of other stuff on the image that might need updating,
which is not in packages either.)

the update process was discussed here for example:
http://volkszaehler.org/pipermail/volkszaehler-users/2013-October/002692.html

a cleaner solution would be to offer (instead of an image)
a repository containing something like a "task-volkszaehler" meta-package.
that could allow for really clean install/updates on any system.
(and could still contain optional raspberry-pi specific setup)
but that would be a completely different task beyond our scope for now, imho.
(the "raspberry pi image" is not ours either.)

[r00t-]

this discussion is completely off-topic by now.
i sugest you open an issue for regularly updated packages if you still want them.

[r00t-]

TODO:
update debian build setup to use cmake.

there is a similar issue with openwrt's build system btw, but that is not ours.
#102
that is also how we found out that the automake build is broken.

[andig]

+1 since it's broken anyway we should remove it. This one is for the C/build experts to grab...

[mbehr1]

+1 from me as well.

Am 17.02.2015 um 10:24 schrieb andig notifications@github.com:

+1 since it's broken anyway we should remove it. This one is for the C/build experts to grab...

—
Reply to this email directly or view it on GitHub #105 (comment).

[r00t-]

your +1 is on applying this PR as-is?
note that it currenly contains a non-working attempt to fix the debian build.
it actually successfully runs cmake,
but something is broken about the way debian sets up the external build-dir.

given that @justinotherguy seems to have given up on his short-term goal of providing debian packages
( http://volkszaehler.org/pipermail/volkszaehler-users/2015-February/005642.html )
i would also say we can just axe automake and fix the packaging later.

so +1 from me too, if you really want to merge this as-is.

[r00t-]

(just noticed i did not push the attempt to fix the debian build yet)

[andig]

but something is broken about the way debian sets up the external build-dir.

@justinotherguy suggesting to merge as-is (+1 from @mbehr1 plus @r00t- plus @andig)