On Mon, Dec 28, 2009 at 08:47:35PM +0000, Daniel Pocock wrote: > Jesse Becker wrote: > > On Sat, Nov 28, 2009 at 08:42, Daniel Pocock <[email protected]> wrote: > > > >> For those following trunk, you may need to bootstrap again, and make > >> sure you have pcre available. > >> > >> I've linked gmond with libpcre so that it can dynamically match the > >> metric names > >> > >> E.g., for the multicpu module, this is the only metric definition that > >> needs to be given to enable all metrics on all cores: > >> > >> metric { > >> name_match = "multicpu_([a-z]+)([0-9]+)" > >> value_threshold = 1.0 > >> title = "CPU-\\2 \\1" > >> } > > > > Oh, that's cool. +1 for me. > > > I've backported to 3.1,
that was a bad idea IMHO, not because the implementation is bad, but because 3.1.3^H4^H5^H6 has been delayed long enough that adding anything else to it this late and therefore resetting the testing cycle would be unwise; specially considering there are other fairly significant fixes/features waiting as well for backport as well. there is also the fact that there was a valid (sorta, even if no code was ever produced otherwise) comment on how this functionality should be made optional (just like python is) and that wasn't discussed further (except on this email after it was committed), neither corrected. lastly, this code makes using multicpu so easy that it will be fairly obvious the module never worked fine to begin with and so it would therefore make more sense to also backport the needed fixes in r2116 (still incomplete), and maybe even the configuration cleanup patches in r2118 which are also somehow related, and also consider better ways to protect users of other platforms than Linux and Cygwin from shooting themselves on the foot by trying to get that module loaded, and which is an even bigger issue. > $ svn log -r2160 > ------------------------------------------------------------------------ > r2160 | d_pocock | 2009-12-28 20:43:54 +0000 (Mon, 28 Dec 2009) | 1 line > > Patch for PCRE support (backport r2112 and r2119) you are missing also r2150 and r2156 and some yet not existent patches so that the dependency will be also in the RPM SPEC and documented in the configuration man page and other needed places. would suggest instead to revert this backport for now. > >> I'd be interested in any feedback on the PCRE dependency. If necessary, > >> the feature can be made into a compile time option so that gmond can > >> build without it. > > > > Yes, an optional compile time option is the way to do this. Use it if > > present, but continue on without it if not present. > > > Is PCRE not available on any platform that we want to support for 3.1? most likely available everywhere (just like python), but since not having it would most likely only imply that the use of the corresponding configuration wouldn't be possible it really makes sense to be considered optional. > If not, then I'll leave the patch as it is, too many #ifdefs can make > the code look messy. The current implementation tries default locations > for pcre, or let's you specify your own version: > > ./configure --with-libpcre=/opt/pcre ideally all that should be needed will be to also have a --enable-pcre or equivalent flag to control how to disable support for this at compile time just like it is possible for python (and that has proven to be really useful for Solaris users AFAIK) being able to use then autoconf like #defines to either enable a dummy implementation of the missing functionality should be all that is needed and shouldn't made the code that ugly (unless it needs refactoring anyway) but I understand if you are looking instead to get the feature initially released without having this as a posibility. Carlo ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
