[PD-dev] autotools magic for externals?

Bryan Jurish moocow at ling.uni-potsdam.de
Thu Nov 29 21:41:17 CET 2007


moin Claude,

On 2007-11-29 20:10:19, Claude Heiland-Allen
<claudiusmaximus at goto10.org> appears to have written:
> So, is there a set of macros I can drop into my acinclude.m4 that
> provide a nice auto-n00b-friendly environment as a base for creating a
> configure.ac and a Makefile.am for a Pd external that requires some
> libraries?

I don't think so.  I ask occasionally on the list if there are any m4
programmers lurking about to help setting up something like you
describe, but so far no one has bitten, and I haven't got around to
learning m4 myself yet.

> I've been trying to use autotools (autoconf and friends) to build pdlua, 
> but have ended up in a world of pain and deleted my experiments out of 
> frustration.  I tried to understand the system used in 
> CVS/externals/moocow/, but the wizardry was somewhat beyond me.  Even 
> more so with the Gem system.

I can't speak for gem's build system, but the autotools conventions in
externals/moocow/* are most definitely to be considered *hacks* (rather
than "wizardry" ;-)  ... for example in 'readdir':

configure.ac or configure.in:
 + the stuff under "how to hack automake EXEEXT conventions" says it
all: automake-1.4 handles the $(EXEEXT) make variable differently than
automake-1.9, but I'm not sure when exactly the change occurred.  The
big idea is that pd externals are built with automake "_PROGRAMS"
targets, but they also need to be installed with a ".pd_whatever"
extension.  So I use EXEEXT to tell automake what that extension is

 + the lines:
   >> PD_OBJECT_EXTERNALS="readdir${buildext}"
   >> AC_SUBST(PD_OBJECT_EXTERNALS)
just substitute @PD_OBJECT_EXTERNALS@ into Makefile from Makefile.am.
You don't need it or anything like it if you know what all your sources
and targets are: I sometimes use PD_OBJECT_EXTERNALS to differentiate
between library and single-object builds (e.g. in pdstring/).

 + the directory arguments & checks should be self explanatory

 + the stuff under "machine-dependent flags" is borrowed (mostly) from
pd's own configure.in, and can probably be left untouched.

config/ subdir:
 + I put autotools-specific stuff here, to avoid cluttering up other
distribution root or source directories

src/ subdir:
 + The guts: set EXEEXT and build externals as pdexterns_PROGRAMS
targets (which is valid since configure.ac did AC_SUBST(pdexternsdir)).
 + pd-style compiler flags are gathered into AM_CPPFLAGS, AM_CFLAGS, and
readdir_LDFLAGS (if you have other libraries to link to, put them in
myprog_LDADD, e.g. "readdir_LDADD = -lfoo -lbar").

... in general, there's probably a lot of junk hanging around in the
various files that you don't need, but (probably) won't hurt ;-)
Certainly ignore and/or delete any rules about $(PODS), unless you're
generating README files out of README.pod in perl's pod format.

If you have specific difficulties and/or questions about my autotools
hacks, don't hesitate to ask -- I freely admit that they're ugly and
cryptic, but they're actually quite adaptable...

marmosets,
	Bryan

-- 
Bryan Jurish                           "There is *always* one more bug."
jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic Entomology




More information about the Pd-dev mailing list