Carlo Marcelo Arenas Belon wrote:
> 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 <dan...@pocock.com.au> 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.
>
>
That is a risk - that is why I have now made it completely optional
> 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.
>
Now this has been done - I've also demonstrated how to do this with a
single configure option, we should consider the same syntax for the
python option
> 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.
>
>
Is it the job of the release manager to apply each backport himself, or
can these tasks be assigned to the people who developed the patches?
I think that exposing the problems in multicpu is not such a bad thing -
hopefully it will encourage people to contribute fixes.
>> $ 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.
>
>
Those changes have been backported
The RPM spec and man page have been updated now
I've also updated the STATUS file
> would suggest instead to revert this backport for now.
>
With the change I have made, do you still believe we should revert this?
>
>>>> 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)
>
To disable it:
./configure --without-libpcre
or
./configure --with-libpcre=no
------------------------------------------------------------------------------
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
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
