On 20/03/12 22:20, Michael Perzl wrote: > On 03/20/2012 06:19 PM, Daniel Pocock wrote: > >> b) should Michael (or anyone else) need to modify Makefile.am from a >> tarball? If there are regular changes to Makefile.am after releases are >> made, shouldn't we find a way to incorporate such changes into trunk, or >> provide more variables for people to set things at build time? >> > Let me explain my "motivation" to make changes to Makefile.am: > > I am maintaining for AIX and Linux on Power a couple of additional gmond > DSO modules written in C. As those are probably only useful for people >
Could you do this with ganglia-modules-linux instead? I'd be happy to apply such patches there if they are good for all Linux systems (or if they don't break it for non-Power builds) You could easily clone ganglia-modules-linux to make ganglia-modules-aix too In fact, the autotools stuff for ganglia-modules-linux was copied from ganglia-modules-solaris: http://gmod-linux.sourceforge.net/ http://gmod-solaris.sourceforge.net/ > running AIX (or Linux on Power) I don't see a generic way to incorporate > such changes into trunk. In order to compile and package the gmond > module I intentionally keep the release tar.gz unchanged, i.e., any > module is represented by a large source code patch against the > respective release tar.gz. This is also the "RPM-way" of doing things > (i.e., keep the vanilla source unchanged and anything else should be > provided as a source code patch). > I agree that RPM (and Debian) supports this, but when it touches Makefile.am, it is not exactly the autotools way of doing things. > So the patch for example for a metric called "mod_netif" adds or changes > the following files/directories: > > ./gmond/modules/conf.d/netif.conf > ./gmond/modules/netif/mod_netif-linux.c > ./gmond/modules/netif/Makefile.am > ./gmond/modules/Makefile.am > ./gmond/Makefile.am > ./configure.in > > Now one needs to run "autoreconf -fi" to incorporate the applied patches > and that the respective "Makefile.in" files are generated from the > patched "Makefile.am" files. > That is actually a really bad idea: because the Ganglia community can only really support one version of autotools at any time (the version used for official release bootstrapping), and bootstrapping again with a different version is likely to give you results that are `unique' to your project. As I mentioned, I'm not insisting that Debian 6.0 (squeeze) is the best platform for bootstrapping, but it is the platform that has been used since it was last discussed in 2009. Using autotools from any other platform is a risk (or at the very least, it creates extra work for you) > I also keep separate SPEC files for all modules and have thus a clean > separation of the original Ganglia release tar.gz files and my modules. > In addition I can change the RPM "release" number independently of the > core ganglia RPM release number which provides further flexibility. > The spec files could go into ganglia-modules-linux if you think that is practical, but there is no obligation to work that way. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
