On 2006-12-14 01:34:07, Hans-Christoph Steiner hans@eds.org 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