I'm a Debian developer, and I've started packaging admb.
Would very much welcome patches suggestions help etc.
When (if) it is whipped into shape it would be my pleasure to upload
it into Debian.
> The debian package build process would need to be completely
> automated in order for the ADMB project maintainers to keep it
> current. Usually, this automation is accomplished using make.
The way this typically works is that the Debian packaging information
per-se goes into a debian/ subdirectory maintained by the Debian
project. Changes outside there are kept minimal: bug fixed, generally
send to and coordinated with the upstream developers, and changes to
make the package build and install in a Debian-friendly way across as
many architectures as possible.
You can see what I've done so far, quite minimal just a quick pass,
via:
git clone git://git.debian.org/git/collab-maint/admb.git
The main pending issues are
(a) The need to do something special on 64-bit architectures to ask
the build system to not use -m32, which I hacked around in an ugly
way on amd64 only; I have no idea how this will work on other
64-bit architectures.
(b) The GNUMakefile generated by ./configure does not use the standard
API. In particular, "make install" does not pay attention to
DESTDIR, and prefix is hardwired at ./configure time rather than
just having a default set, and even at ./configure time particular
system target directories are not set using the standard names, in
particular it is hard to get /usr/bin to hold only user-callable
things, /usr/lib/admb to hold architecture-specific things,
/usr/share/amdb to hold non-arch-specific things, and
/usr/share/doc/amdb to hold all documentation. As is, /usr/bin/
would end up containing, e.g., all sorts of non-executables, like
sed script fragments and such.
(c) Although this could be hacked around with shell scripts wrappers,
ideally the executables would have a default value to ADMB_HOME
(or really its relevant components) which are used if that env
variable is not set, and those defaults would be set by passing
things constructed in the makefiles out of prefix & friends using
CPPFLAGS+=-MADMB_HOME_DEFAULT=\"$(prefix)...\" Icky I know.
(d) It seems like generating shared (i.e., dynamic) libraries would be
a good idea. Is there some reason that would be a bad idea?
(e) Man pages, even if they are short stubs...
(f) There are things happening at build time, like invoking
svnversion, that (1) might not be very robust, like if the build
is not in an SVN repo as in my case, and (2) require build-time
dependencies that will cause a lot of work for the debian
autobuilders. It would be good to have all "true" build-time
dependencies documented in, eg, README.txt. lex? flex?
I'm torn between doing something ad-hoc vs rejiggering the build
system to more fully integrate autotools and maybe automake. And
working around some of the above. Trying to rejigger the build to
generate dynamic libraries. A bit more than I'd bargained for!
Cheers,
--Barak.
--
Prof Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
_______________________________________________
Developers mailing list
Develop...@admb-project.org
http://lists.admb-project.org/mailman/listinfo/developers
