RFS: EngLab

[Bernhard R. Link]

* Harry Serenis <chserenis at ee.auth.gr> [081007 01:31]:
> The build rules were renamed to build-libenglab and
> build-libenglab-dev. The 2 packages are now configured and build in
> separate subdirectories out-of-tree, hence they can be built
> concurrently

* They still also do the installing, which is a bit confusing.

The usual way is to have build targets, which are somehow (for example
by being prerequisites to build or build-arch and/or build-indep) called
by build and some code (be it install targets or direct invocation from
some binary-* target) to install those files.

This has the following advantages:

- make install must be run as root (dangerous) or under fakeroot
(a bit slower and might confuse some autodetection like adding fakeroot
LDPRELOADS into libraries with strange build systems), thus splitting
this in parts makes it easy to run as much as possible as non-root and
only the needed things as root/fakeroot.

- someone doing local modifications of the package can build it and
then modify the package creation part multiple times without having to
rebuild the package again and again when just adding a single dependency
(or removing it) to debian/control.

* configure-* is phony, build-libeng* creates non-working stamp files.

The commands of your build-libeng* create the target files. This is
usually done to avoid make calling that target again once it was done
in an earlier make call. If you keep the make install calls in there
that does not make much sense. if you move the install calls out of
there (and make build or build-arch/indep depend on those targets), you
will still need to also ass touch $@ or equivalent to the
configure-libeng* rules (otherwise make will see that no configure-*
files are there, run that again, and then run the build-* again because
one of their prerequisites was just run).

I'd suggest something like:

...as before...

configure-libenglab:
        ....
        touch $@
configure-libenglab-dev:
        ....
        touch $@
build-libenglab: configure-libenglab
        dh_testdir
        cd libenglab && $(MAKE) $(MAKEFLAGS)
        touch $@
build-libenglab-dev: configure-libenglab-dev
        dh_testdir
        cd libenglab-dev && $(MAKE) $(MAKEFLAGS)
        touch $@
build-arch: build-libenglab build-libenglab-dev
build: build-arch
build-indep:
install: build-libenglab build-libenglab-dev
        dh_testdir
        dh_testroot
        dh_clean -k
        cd libenglab-dev && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
        rm -f $(CURDIR)/debian/tmp/usr/share/doc/libenglab/COPYING
# I do not understand why you did this, especially after -dev?
        rm -f $(CURDIR)/debian/tmp/usr/lib/libenglab.so
        cd libenglab && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install
        rm -f debian/tmp/usr/share/doc/libenglab/COPYING

binary-indep:
#        nothing to do.

binary-arch: install
        ...

binary: binary-indep binary-arch
.PHONY: build-arch build-indep build clean binary-indep binary-arch binary install

Of course install can also be moved into binary-arch, both can be seen
as a little bit cleaner...

Installing both builds into the same debian/tmp dir means you have to be
carefull when putting things there twice. I think you install the
scripts both times, so you should make it is deterministic which are choosen,
even if both should be the same. (having one install target for both
should allow for this). The same might be intresting for config.h

> soversion now has only one number and we intend to keep it this way.

having a libenglib.so.1 -> libenglib.so.0.2.5 is a bit confusing.
(But should have no other negative impacts, as far as I know the long
name is not used by anything).

> We corrected all the warning messages.

Nice.

Sadly building C++ seems to make my unstable box run out of memory, so I
might need a bit before looking a bit deeper at it than a shallow look.

Hochachtungsvoll,
	Bernhard R. Link