automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Implementing a plugin-like module


From: Stefano Lattarini
Subject: Re: Implementing a plugin-like module
Date: Thu, 4 Aug 2011 19:57:34 +0200
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Thursday 04 August 2011, Sam Varshavchik wrote:
>
> [SNIP]
>
> I also came up with a different solution last night. I install something  
> like this into /usr/share/aclocal:
> 
> AC_DEFUN([LIBX_INIT],[
> PKG_PROG_PKG_CONFIG
> PKG_CHECK_EXISTS([libx],[:],[AC_MSG_ERROR([libx not found])])
> 
> libx_pkgdatadir="`$PKG_CONFIG --variable=pkgdatadir libx`"
> 
> LIBX_AM="include $libx_pkgdatadir/msgdispatcher.am"
> AC_SUBST([LIBX_AM])
> ])
> 
> Then, I add
> 
> LIBX_INIT
> 
> to the configure.ac and add
> 
> @LIBX_AM@
> 
> in Makefile.am; and aclocal ends up automatically adding the m4 macro to  
> aclocal.m4, which gets expanded into configure.in. At runtime, configure  
> picks up the toolkit's installation directory, and creates an include  
> statement that references it, which gets SUBST-ed into the Makefile.
> 
> Rather than having automake handle the inclusion, it's left up to gmake;
> but my build-rules are already gmake-specific, and this wouldn't be an  
> additional requirement.
> 
An important difference is that, with your usage, "msgdispatcher.am"
won't be processed by automake, so that you won't be able to use
Automake contructs in it.  If that is unimportant for you, at least
consider renaming "msgdispatcher.am" to, say, "msgdispatcher.mk", to
clearly show that the file is a simple makefile fragment, and is not
intended to be processed by automake.

Regards,
  Stefano



reply via email to

[Prev in Thread] Current Thread [Next in Thread]