variables in _SOURCES
According to the "Warning" in this page[1], it is not permitted to use variables in _SOURCES. Is this deliberate or is it a bug? In our project, we started getting the warnings about subdir-objects and so we added[2] AM_INIT_AUTOMAKE([foreign subdir-objects]) However, since that time the build has been failing[3] and it appears to be because one module[4] is using a variable in _SOURCES The $PYCXX_SRCDIR variable is used to refer to the sources provided by the PyCXX[5] library. PyCXX is not distributed as a compiled library that can be linked against, the sources are simply placed under /usr/share by the packages (e.g. on Debian[6]) and users have to compile them into their projects by referring to them from their Makefile. What is the recommended way of using such sources in a build? I could write some Makefile rule to copy or symlink the sources in to the tree, but is there an official way to solve this with autotools? More specifically, I am using them like this: configure: ./configure ... \ --with-python \ PYCXX_SRCDIR=/usr/share/python2.7/CXX/Python2 Makefile.am: nodist_libpyroute_la_SOURCES = $(PYCXX_SRCDIR)/cxxextensions.c nodist_libpyroute_la_SOURCES += $(PYCXX_SRCDIR)/cxx_extensions.cxx nodist_libpyroute_la_SOURCES += $(PYCXX_SRCDIR)/cxxsupport.cxx nodist_libpyroute_la_SOURCES += $(PYCXX_SRCDIR)/../IndirectPythonInterface.cxx 1. https://autotools.io/automake/nonrecursive.html 2. https://github.com/resiprocate/resiprocate/commit/fb37bc86db9f1b7d569eb2a17acd1e683b6ce55f 3. https://travis-ci.org/resiprocate/resiprocate/builds/131873177 4. https://github.com/resiprocate/resiprocate/blob/master/repro/plugins/pyroute/Makefile.am 5. http://cxx.sourceforge.net/ 6. https://packages.debian.org/search?searchon=contents&keywords=cxxextensions.c&mode=path&suite=stable&arch=any
appending LDADD to prog_LDADD
I understand from the docs that specifying prog_LDADD will override LDADD (and the same for prog_CPPFLAGS, ...) http://www.gnu.org/software/automake/manual/html_node/Linking.html If it is desired to merge prog_LDADD and LDADD, is there any recommended or preferred solution? I've tried LDADD = -lfoo LDADD += -lrt prog_LDADD = -lfoo $(LDADD) and it seems to work for me - if this is the way to go, could it be included in the manual page perhaps?
only installing shared versions of some libs
I've recently adapted a project to support DSO plugins/modules The existing project includes normal libraries and binaries. In a normal build, we want to a) build and install the shared and static versions of the normal libraries b) only install the shared versions of the plugins I don't mind whether static versions of the plugins are built (we don't currently use them) but I would prefer that "make install" does not install them Can anybody comment on the best way to do this? The Makefile.am is linked from here (repro/plugins/example/Makefile.am): http://list.resiprocate.org/archive/resiprocate-commit/msg07875.html
make dist for both Debian and Fedora?
Hi, I use a Debian system to run autoreconf and bootstrap/make dist releases for various projects (e.g. reSIProcate) When using the release tarball on a system like Fedora, issues with hard-coded rpath have been discovered. Apparently I am not alone, and this discussion has come up before in RPM packaging. On the RPM packaging request for reSIProcate, I've gathered links to a few different discussions about the issue: https://bugzilla.redhat.com/show_bug.cgi?id=892625#c11 One proposed solution appears to involve using sed to hack the configure script into shape. A more elegant solution appears to be re-running autoreconf during the rpmbuild (before the call to configure) Is there any other way to deal with this issue without any hacks? Am I potentially doing something wrong when I bootstrap the releases? Regards, Daniel
Re: AIX shared libraries, make install misses them
Ralf Wildenhues wrote: Hello Michael, * Michael Perzl wrote on Fri, Jan 29, 2010 at 07:46:57PM CET: That is without the "-Wl,-brtl" passed to LDFLAGS, so libtool is behaving correctly on AIX to put the modcpu.so into the modcpu.a library archive. The "misbehavior" is that the "*.a" containing the "*.so" files are not installed as expected: You say that but then you (as well as Daniel) quote a line ... /opt/freeware/bin/bash ../../../libtool --mode=install ../../../build/install-sh -c 'modcpu.la' '/var/tmp/gg/lib/ganglia/modcpu.la' ../../../build/install-sh -c .libs/modcpu.a /var/tmp/gg/lib/ganglia/modcpu.a ... that shows the .a file being installed. Now, what's the matter here? Does libtool print that line but not execute it? Does it execute it but the library is installed into the wrong place? Please explain. Hi Ralf, You can see the `make install' output, the build tree, and the install tree here: http://www.pocock.com.au/ganglia/test/aix/michael/ If you look at the install tree: http://www.pocock.com.au/ganglia/test/aix/michael/ganglia-install.tar.gz2-file-list.txt you will see that modcpu.a was never actually installed, despite the output from `make install' Regards, Daniel
Re: AIX shared libraries, make install misses them
Ralf Wildenhues wrote: Hello Michael, * Michael Perzl wrote on Fri, Jan 29, 2010 at 07:46:57PM CET: That is without the "-Wl,-brtl" passed to LDFLAGS, so libtool is behaving correctly on AIX to put the modcpu.so into the modcpu.a library archive. The "misbehavior" is that the "*.a" containing the "*.so" files are not installed as expected: You say that but then you (as well as Daniel) quote a line ... /opt/freeware/bin/bash ../../../libtool --mode=install ../../../build/install-sh -c 'modcpu.la' '/var/tmp/gg/lib/ganglia/modcpu.la' ../../../build/install-sh -c .libs/modcpu.a /var/tmp/gg/lib/ganglia/modcpu.a ... that shows the .a file being installed. Now, what's the matter here? Does libtool print that line but not execute it? Does it execute it but the library is installed into the wrong place? Please explain. ../../../build/install-sh -c .libs/modcpu.lai /var/tmp/gg/lib/ganglia/modcpu.la That line appears in the `make install' output However, the .a files are missing from the tree - every other file appears in the tree
Re: AIX shared libraries, make install misses them
Daniel Pocock wrote: Ralf Wildenhues wrote: Hello Daniel, * Daniel Pocock wrote on Thu, Jan 28, 2010 at 03:21:24PM CET: We have been working on getting the Ganglia tarball to work out of the box for AIX When Michael does `make install', the *.so files for our modules are not installed. Instead, he sees output like this from `make install': -- /opt/freeware/bin/bash ../../../libtool --mode=install ../../../build/install-sh -c 'modcpu.la' '/var/tmp/gg/lib/ganglia/modcpu.la' ../../../build/install-sh -c .libs/modcpu.a /var/tmp/gg/lib/ganglia/modcpu.a ../../../build/install-sh -c .libs/modcpu.lai /var/tmp/gg/lib/ganglia/modcpu.la I've looked at the file gmond/modules/cpu/.libs/modcpu.la on AIX: ... dlname='modcpu.so' library_names='modcpu.a modcpu.a' old_library='' Is that without or with runtimelinking enabled (LDFLAGS=-Wl,-brtl passed to configure)? If without, then libtool puts the modcpu.so file into the modcpu.a archive (the way AIX does with its system modules as well) and that is to be expected. With runtimelinking, the .so file should be a separate file. That makes sense - I don't believe Michael has run it with the different LDFLAGS yet. However, nothing gets installed - if the default behavior is to create modcpu.a, then shouldn't `make install' result in the installation of modcpu.a? For changing LDFLAGS, I'd rather include this into configure.in, so it will be set automatically for AIX platforms. Can you make any suggestions on that? The project involves building some static libraries, shared libraries, and linking some of the static libraries to create an executable too. Will option be necessary for all such targets, or do I need to use it selectively? I've looked at the manual for -brtl and it tells me that the flag is needed for building targets that depend on other shared objects. The gmond executable itself loads various other modules (shared objects) using dlopen(), and gmond also depends on system libraries. The modules themselves depend on some other shared libraries in the system. Therefore, I think -brtl is needed for everything we build and could potentially be added to LDFLAGS for AIX in configure.in BTW, you didn't specify any bug or misbehavior that you see, so maybe everything else works as expected? Yes, an earlier email I have from Michael says that it runs if the modules are copied over manually - I'm not sure if he was copying *.a or *.so however. Finally, Michael reports that if he bootstraps again with his own autoconf, make install does work. Here is Michael's autotools versions: autoconf-2.64-1 automake-1.11.1-1 libtool-1.5.26-1 libtool-ltdl-1.5.26-1 libtool-ltdl-devel-1.5.26-1 m4-1.4.13-1 And here are the versions on Debian 5 (used for bootstrapping the release tarball): autoconf 2.61-8 automake 1:1.10.1-3 libtool 1.5.26-4 m4 1.4.11-1 Is there any way we can get this working using the existing autotools version? Well, I really don't know the differences between libtool-1.5.26-1 and libtool 1.5.26-4 (this really all is a libtool issue, not an Automake one), but if there were bugs in either, I'd first ask you to retry with 2.2.6b anyway. Another problem I have just discovered, on Cygwin, I have to patch libtool, adding the line echo="echo" otherwise I get lot's of errors along the lines of "Xgcc command not found" This is a pretty sure sign that you have mixed up macros from one Libtool version with a ltmain.sh file from another Libtool version. Perchance your aclocal.m4 or acinclude.m4 files contain old Libtool macro definitions? I'll be checking that out shortly - thanks for this tip Ok, here is what I found: - the system where I bootstrap has libtool 1.5.26-4 - the Cygwin system where I run configure and make has libtool 2.2.7a - various files like aclocal.m4 are included in the tarball from the bootstrap host http://www.pocock.com.au/ganglia/test/ - some files, like acinclude.m4, are included in SVN http://ganglia.svn.sourceforge.net/viewvc/ganglia/branches/monitor-core-3.1/ Is there some way we can fix this so that the user running configure won't have to worry about which version of libtool they have?
Re: AIX shared libraries, make install misses them
Ralf Wildenhues wrote: Hello Daniel, * Daniel Pocock wrote on Thu, Jan 28, 2010 at 03:21:24PM CET: We have been working on getting the Ganglia tarball to work out of the box for AIX When Michael does `make install', the *.so files for our modules are not installed. Instead, he sees output like this from `make install': -- /opt/freeware/bin/bash ../../../libtool --mode=install ../../../build/install-sh -c 'modcpu.la' '/var/tmp/gg/lib/ganglia/modcpu.la' ../../../build/install-sh -c .libs/modcpu.a /var/tmp/gg/lib/ganglia/modcpu.a ../../../build/install-sh -c .libs/modcpu.lai /var/tmp/gg/lib/ganglia/modcpu.la I've looked at the file gmond/modules/cpu/.libs/modcpu.la on AIX: ... dlname='modcpu.so' library_names='modcpu.a modcpu.a' old_library='' Is that without or with runtimelinking enabled (LDFLAGS=-Wl,-brtl passed to configure)? If without, then libtool puts the modcpu.so file into the modcpu.a archive (the way AIX does with its system modules as well) and that is to be expected. With runtimelinking, the .so file should be a separate file. That makes sense - I don't believe Michael has run it with the different LDFLAGS yet. However, nothing gets installed - if the default behavior is to create modcpu.a, then shouldn't `make install' result in the installation of modcpu.a? For changing LDFLAGS, I'd rather include this into configure.in, so it will be set automatically for AIX platforms. Can you make any suggestions on that? The project involves building some static libraries, shared libraries, and linking some of the static libraries to create an executable too. Will option be necessary for all such targets, or do I need to use it selectively? BTW, you didn't specify any bug or misbehavior that you see, so maybe everything else works as expected? Yes, an earlier email I have from Michael says that it runs if the modules are copied over manually - I'm not sure if he was copying *.a or *.so however. Finally, Michael reports that if he bootstraps again with his own autoconf, make install does work. Here is Michael's autotools versions: autoconf-2.64-1 automake-1.11.1-1 libtool-1.5.26-1 libtool-ltdl-1.5.26-1 libtool-ltdl-devel-1.5.26-1 m4-1.4.13-1 And here are the versions on Debian 5 (used for bootstrapping the release tarball): autoconf 2.61-8 automake 1:1.10.1-3 libtool 1.5.26-4 m4 1.4.11-1 Is there any way we can get this working using the existing autotools version? Well, I really don't know the differences between libtool-1.5.26-1 and libtool 1.5.26-4 (this really all is a libtool issue, not an Automake one), but if there were bugs in either, I'd first ask you to retry with 2.2.6b anyway. Another problem I have just discovered, on Cygwin, I have to patch libtool, adding the line echo="echo" otherwise I get lot's of errors along the lines of "Xgcc command not found" This is a pretty sure sign that you have mixed up macros from one Libtool version with a ltmain.sh file from another Libtool version. Perchance your aclocal.m4 or acinclude.m4 files contain old Libtool macro definitions? I'll be checking that out shortly - thanks for this tip
Re: AIX shared libraries, make install misses them
Daniel Pocock wrote: We have been working on getting the Ganglia tarball to work out of the box for AIX The tarball is bootstrapped using autotools on Debian 5. When Michael does `make install', the *.so files for our modules are not installed. Instead, he sees output like this from `make install': -- /opt/freeware/bin/bash ../../../libtool --mode=install ../../../build/install-sh -c 'modcpu.la' '/var/tmp/gg/lib/ganglia/modcpu.la' ../../../build/install-sh -c .libs/modcpu.a /var/tmp/gg/lib/ganglia/modcpu.a ../../../build/install-sh -c .libs/modcpu.lai /var/tmp/gg/lib/ganglia/modcpu.la -- Libraries have been installed in: /var/tmp/gg/lib/ganglia If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LIBPATH' environment variable during execution - use the `-Wl,-blibpath:LIBDIR:/opt/freeware/lib:/usr/vac/lib:/usr/lib/threads:/usr/lib:/lib ' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. - I've looked at the file gmond/modules/cpu/.libs/modcpu.la on AIX: ... dlname='modcpu.so' library_names='modcpu.a modcpu.a' old_library='' ... and when I run make && make install on Linux (a RHEL4 box), gmond/modules/cpu/.libs/modcpu.la has: ... dlname='modcpu.so' library_names='modcpu.so modcpu.so modcpu.so' old_library='modcpu.a' ... Finally, Michael reports that if he bootstraps again with his own autoconf, make install does work. Here is Michael's autotools versions: autoconf-2.64-1 automake-1.11.1-1 libtool-1.5.26-1 libtool-ltdl-1.5.26-1 libtool-ltdl-devel-1.5.26-1 m4-1.4.13-1 And here are the versions on Debian 5 (used for bootstrapping the release tarball): autoconf 2.61-8 automake 1:1.10.1-3 libtool 1.5.26-4 m4 1.4.11-1 Is there any way we can get this working using the existing autotools version? Another problem I have just discovered, on Cygwin, I have to patch libtool, adding the line echo="echo" otherwise I get lot's of errors along the lines of "Xgcc command not found" Previous Ganglia tarballs bootstrapped with older autotools were fine on Cygwin
AIX shared libraries, make install misses them
We have been working on getting the Ganglia tarball to work out of the box for AIX The tarball is bootstrapped using autotools on Debian 5. When Michael does `make install', the *.so files for our modules are not installed. Instead, he sees output like this from `make install': -- /opt/freeware/bin/bash ../../../libtool --mode=install ../../../build/install-sh -c 'modcpu.la' '/var/tmp/gg/lib/ganglia/modcpu.la' ../../../build/install-sh -c .libs/modcpu.a /var/tmp/gg/lib/ganglia/modcpu.a ../../../build/install-sh -c .libs/modcpu.lai /var/tmp/gg/lib/ganglia/modcpu.la -- Libraries have been installed in: /var/tmp/gg/lib/ganglia If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LIBPATH' environment variable during execution - use the `-Wl,-blibpath:LIBDIR:/opt/freeware/lib:/usr/vac/lib:/usr/lib/threads:/usr/lib:/lib ' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. - I've looked at the file gmond/modules/cpu/.libs/modcpu.la on AIX: ... dlname='modcpu.so' library_names='modcpu.a modcpu.a' old_library='' ... and when I run make && make install on Linux (a RHEL4 box), gmond/modules/cpu/.libs/modcpu.la has: ... dlname='modcpu.so' library_names='modcpu.so modcpu.so modcpu.so' old_library='modcpu.a' ... Finally, Michael reports that if he bootstraps again with his own autoconf, make install does work. Here is Michael's autotools versions: autoconf-2.64-1 automake-1.11.1-1 libtool-1.5.26-1 libtool-ltdl-1.5.26-1 libtool-ltdl-devel-1.5.26-1 m4-1.4.13-1 And here are the versions on Debian 5 (used for bootstrapping the release tarball): autoconf 2.61-8 automake 1:1.10.1-3 libtool 1.5.26-4 m4 1.4.11-1 Is there any way we can get this working using the existing autotools version?
Re: AIX linking: -berok in aclocal.m4 and libtool
Ralf Wildenhues wrote: Hello Daniel, * Daniel Pocock wrote on Sat, Jan 16, 2010 at 02:09:55PM CET: Could anyone share any advice on using autoconf and automake to prepare a distribution tarball that will work on AIX? Normally, I build the tarball on Linux (Debian 5). The AIX users need to be able to use the tarball to build an executable (gmond), a static library (libmetrics) and a bunch of DSOs (e.g. modcpu.so)? Some AIX users of Ganglia have raised queries about the -berok linker flag in aclocal.m4, and whether it is necessary to patch aclocal.m4 to remove this flag. We're also trying various other things to improve the AIX support, e.g. adding "-Wl,-bexpfull" to LDFLAGS or GLDFLAGS in various places. This all comes out of - bug report (Ganglia bug 227) http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=227 - and subsequent email discussion http://www.mail-archive.com/ganglia-develop...@lists.sourceforge.net/msg05463.html I haven't looked into this in detail yet; I would like to, but it might be a while. Is the source code of this package available for download (URL)? What other software would I need to build this? Thanks. I've created a branch for testing on AIX: http://ganglia.svn.sourceforge.net/viewvc/ganglia/branches/monitor-core-3.1-aix/ Snapshots of the AIX branch and release branch are here: http://www.pocock.com.au/ganglia/test/ A few general comments: This is probably a Libtool issue rather than an Automake one. I noticed in the PR a diff against libtool. I hope you're not putting the generated libtool script in version-control anywhere. It is not in SVN, it is put there when we bootstrap - Michael has been applying the diff after downloading the tarball. I want to improve the tarball so he won't need to do this. Issues with modules on AIX are often fixed most easily by using runtimelinking. You enable that with libtool by adding -Wl,-brtl to LDFLAGS at configure time: ./configure LDFLAGS=-Wl,-brtl This has a small performance impact, which is why it is not the default. Thanks for this suggestion - we will try that and add it to the docs for AIX users. Ganglia is essentially a performance monitoring agent, so we are keen to minimize any impact it has on the machine. Does this -brtl option just impact the performance at the time when the shared object is loaded, or does it impact ever function call?
AIX linking: -berok in aclocal.m4 and libtool
Hi, Could anyone share any advice on using autoconf and automake to prepare a distribution tarball that will work on AIX? Normally, I build the tarball on Linux (Debian 5). The AIX users need to be able to use the tarball to build an executable (gmond), a static library (libmetrics) and a bunch of DSOs (e.g. modcpu.so)? Some AIX users of Ganglia have raised queries about the -berok linker flag in aclocal.m4, and whether it is necessary to patch aclocal.m4 to remove this flag. We're also trying various other things to improve the AIX support, e.g. adding "-Wl,-bexpfull" to LDFLAGS or GLDFLAGS in various places. This all comes out of - bug report (Ganglia bug 227) http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=227 - and subsequent email discussion http://www.mail-archive.com/ganglia-develop...@lists.sourceforge.net/msg05463.html Regards, Daniel
Re: making config files
You probably mean $(top_builddir) Thanks - I'll fix that one %: %.tmpl $(FIXCONFIG) $(FIXCONFIG) $< AFAIU, %: %.tmpl is GNU Make specific and won't work with other makes. I realised the same thing and took it out and put something like the following into each Makefile.am: include $(top_srcdir)/ganglia.inc bin_SCRIPTS = ganglia-config The problem with doing this via a config script is that it will not honor a sequence such as: ./configure make prefix=/opt make install because the value '/opt' will not propagate to the generated files. It is required by GNU Coding Standards, but of course something you can completely ignore as long as you don't claim you follow GCS. Yes, I realise that would happen - that's why I'm trying to find another way to do it However, things like ganglia-config should be generated during the install phase, although the default behavior for the _SCRIPTS primary appears to be processing ganglia-config.in during the build phase - is there a recommended way it can be influenced to delay processing until the install phase? I don't understand why you are against creating files during 'make all', but couldn't automake's install-exec-local target help you here? That is what I have done actually - but I wanted something more concise, e.g. bin_GENSCRIPTS = script1 script2 script3 with all the logic happening behind the scenes. Currently I have to list a rule (at least two lines of code) for each of script1, script2, ... My current implementation is now in SVN, would you mind having a quick look at my Makefile.am and gmond/Makefile.am? Is this the right way to use the install-* rules? http://ganglia.svn.sourceforge.net/viewvc/ganglia/trunk/monitor-core/
Re: making config files
Russ Allbery wrote: Daniel Pocock writes: Thanks for that - the sed example appears to be the type of thing I want. However, is there a more concise way to do this? I was thinking there may be some way to invoke sed or m4 on a template in much the way that gcc is invoked for *.c Half of that equation would be a more generic script. Attached is what we use for INN (which has a bunch of INN-specific bits, but also has the basic framework for things). The script seems fine - I've located it in your source tree here http://inn.eyrie.org/svn/trunk/support/ and examples of how you use it here: http://inn.eyrie.org/svn/trunk/scripts/ The other half would be to set up a way of automatically running that script on particular files, and that's something I've never done. I just write explicit rules. This is what interests me - although I could list out the rules for each target, I would like to try and do everything with automake This is how I've been going about it: create $(top_srcdir)/ganglia.inc like so: FIXCONFIG = $(top)/scripts/fixconfig %: %.tmpl $(FIXCONFIG) $(FIXCONFIG) $< and put something like the following into each Makefile.am: include $(top_srcdir)/ganglia.inc bin_SCRIPTS = ganglia-config However, things like ganglia-config should be generated during the install phase, although the default behavior for the _SCRIPTS primary appears to be processing ganglia-config.in during the build phase - is there a recommended way it can be influenced to delay processing until the install phase?
Re: making config files
Russ Allbery wrote: Daniel Pocock writes: Thanks for that - the sed example appears to be the type of thing I want. However, is there a more concise way to do this? I was thinking there may be some way to invoke sed or m4 on a template in much the way that gcc is invoked for *.c Half of that equation would be a more generic script. Attached is what we use for INN (which has a bunch of INN-specific bits, but also has the basic framework for things). The other half would be to set up a way of automatically running that script on particular files, and that's something I've never done. I just write explicit rules. Hi Russ, Thanks for this - it may be just what we need to get some nasty hacks out of configure.in In case I use this as-is, can you kindly confirm that it is compatible with the Ganglia license? http://ganglia.svn.sourceforge.net/viewvc/ganglia/trunk/monitor-core/COPYING?revision=560&view=markup Regards, Daniel
Re: making config files
Peter Johansson wrote: Daniel Pocock wrote: Therefore, I felt that I should be aiming to have the config files generated at the last moment - probably during `make install', just before they are installed. Can anyone suggest best practice for doing this? please refer to http://www.gnu.org/software/autoconf/manual/autoconf.html#Installation-Directory-Variables Thanks for that - the sed example appears to be the type of thing I want. However, is there a more concise way to do this? I was thinking there may be some way to invoke sed or m4 on a template in much the way that gcc is invoked for *.c
making config files
Hi,
I've been working on a project, Ganglia, that is built with autotools
Included in the source tree are templates for various configuration
files (e.g. modpython.conf.in). Some of these include hard coded paths.
It seems appropriate to replace the hardcoded paths with substitutions
(e.g. @sysconfdir@) - however, if the template is processed by
configure, then the generated config file sometimes includes a value
like ${prefix}/etc rather than an absolute path like /opt/ganglia-3.1/etc
Therefore, I felt that I should be aiming to have the config files
generated at the last moment - probably during `make install', just
before they are installed. Can anyone suggest best practice for doing this?
Regards,
Daniel
