[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