autools build (was: [PD-dev] branch-v0-39-2-extended created)

Bryan Jurish moocow at ling.uni-potsdam.de
Thu Dec 14 12:56:57 CET 2006


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

-- 
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