On 2006-12-14 01:34:07, Hans-Christoph Steiner [EMAIL PROTECTED] appears to
have written:
On Dec 13, 2006, at 3:41 AM, Bryan Jurish wrote:
yup, i use a hacked Makefile.am for my pd externals, because the builtin
targets (install, uninstall, dist, clean, etc.) are so darned handy.
still, there's no reason why i couldn't pack in a default makefile as
well.
Perhaps an even better approach would be to help me figure out how to do
everything with autoconf and automake, replacing externals/Makefile.
eek.
well, i've now read the README and had a look at the developer docs on
puredata.org, but i'm still a bit baffled as to how the whole build
system hangs together (haven't spent much time perusing the actual
makefiles yet).
as to using the autotools for building pd externals, using my current
conventions, I'd estimate that it's actually more effort (for the
developer) than tailoring the 'template' section of externals/Makefile:
basically, what I do (well, the relevant bits anyways) for a new
external library (see pdstring or gfsm for examples) is the following
[might not be very helpful, but i had to refresh my memory, so here it is]:
in configure.in [now officially configure.ac, but I'm lazy]:
+ add configure arguments using AC_ARG_WITH:
--with-pd-dir=DIR
* default=/usr/local/pd
* sets $(pddir) and $(pddocdir), for installation
--with-pd-extdir=DIR
* default=$PD_DIR/externs
* sets $(pdextternsdir), for installation
--with-pd-include=DIR
* default=$PD_DIR/src
* sets $(pdincludedir), for compiler flags
+ sanity check for m_pd.h with AC_CHECK_HEADER
+ (do whatever checks are necessary for the external: gfsm, etc.)
+ set machine-dependent compiler flags and PDEXT
(copied from pd's own configure.in)
+ if the package supports multiple-external-library and single-file
build modes, add arguments for selection and set a variable
(i use PD_OBJECT_EXTERNALS) that gets used in src/Makefile.am
to set pdexterns_PROGRAMS
~ there's actually no such argument in pdstring, but there could be
in src/Makefile.am:
+ major ugly nasty hack: set EXEEXT=.$(PDEXT)
~ so I can use *_PROGRAMS targets to for externals
+ easy stuff (similar to Makefile 'template' tailoring):
~ set pdexterns_PROGRAMS (pdexterns_EXTRA_PROGRAMS) to the externals
I (might) want to build
~ set pdexterns_DATA to any abstractions I want to install
~ set pddoc_DATA to any help patches I want to install
~ set myextern_SOURCES to the actual source files for 'mylibrary'
~ adopt compiler and linker flags into AM_CPPFLAGS, AM_CFLAGS,
AM_CXXFLAGS, mylibrary_LDFLAGS
~ add distributed pd patches to EXTRA_DIST
... i also use a config/ subdir (AC_CONFIG_AUX_DIR) to keep the
autotools files out of the package root directory, but that's more
hindrance than help for a template-like system, and shouldn't really
make any difference at all.
that having been said, i think the right way to do it would actually
be to write a small common set of m4 macros that developers could just
call from configure.(in|ac) and use in Makefile.am, analagous to
AM_INIT_AUTOMAKE() or AM_PROG_LIBTOOL(); call it something like
'PUREDATA_BUILD_INIT()', which could take care of all of the
configure.(in|ac) manipulations, as well as the various FLAGS variables.
Heck, maybe we could even use libtool directly...
setting EXEEXT=.$(PDEXT) is very very ugly, i admit. the right thing
to do here (im(ns)ho) would really be just to tweak the automake
$(whatever_)PROGRAMS expansion code into something like
$(whatever_)PDEXTERNS. The default install dir for _PDEXTERNS targets
could then be set to $(pdexternsdir) [vs. $(bindir) for _PROGRAMS], so
just setting PDEXTERNS = any2string string2any would suffice.
Similarly for documentation (PDDOCS?), abstractions (PDPATCHES?),
etc. A default configure.in could even be made available which performs
all of the basic configuration (AC_PROG_CC, AM_INIT_AUTOMAKE,
PUREDATA_BUILD_INIT), for those who don't need/want additional autoconf
checks.
getting all of that to work properly and transparently would be pretty
heavy on the m4 coding side, and I've only ever used m4 in a very
rudimentary capacity (stupid string substitution). it would have
advantages (centralized administration of compiler flags for known
architectures, conventional default directories, install, uninstall,
dist, distcheck targets, etc. etc.), but sounds like more than i can
personally chew at the moment [cf. signature] ;-)
marmosets,
Bryan
--
Bryan Jurish There is *always* one more bug.
[EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
