On Wed, Jul 02, 2008 at 12:26:18PM -0600, Brad Nicholes wrote: > >>> On 7/2/2008 at 12:16 PM, in message <[EMAIL PROTECTED]>, Carlo > Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > > On Wed, Jul 02, 2008 at 11:11:08AM -0600, Brad Nicholes wrote: > >> >>> On 7/2/2008 at 5:12 AM, in message <[EMAIL PROTECTED]>, Carlo > > Marcelo > >> Arenas Belon <[EMAIL PROTECTED]> wrote: > >> > The following proposed patch for stable 3.1, removes all references to > >> > C++ > >> > as a supported language for building DSO metrics as it was reportedly not > >> > working. > >> > > >> > The changes required to get mod_example.c to compile using the GNU C++ > >> > compiler (which are rather intrusive) are already committed in trunk and > >> > proposed for integration for the next release. > >> > > >> > Contains changes from r1490. > >> > > >> > Carlo > >> > --- > >> > >> Even though the language label of "C/C++" might be a little misleading for > > now, it is still a more meaningful language label than "c". > > > > I would argue otherwise, as "c" semantics will be more meaningful to an > > "Objective C" or "C#" interface than "C/C++", and they all might be possible > > in the long run. > > > > Indeed I would even argue that "C/C++" is too limiting because any other > > compiled language that is able to use "c" semantics might be represented > > here > > as well. > > > The only reason why the labels are "C/C++", "Python", etc. rather than > "Compiled", "Scripted" is because I wanted to leave a little flexibility > incase there is some special handling of certain class of modules in the > future.
I always assumed (as explained in the comments in the code) it was so the right module interface could be selected, and will be definitely important as soon as other language interfaces like "perl", "lua" or "visual basic" start getting added. > This configuration directive is only meant to roughly identify the module > class, not to uniquely identify the language it was developed in. the documentation was probably misleading with so many references to the the "C" language then. > If there is no real reason to make the end user jump through any extra hoops, > then let's not do it. By the same token, if there really isn't any reason > to make the code more complex (even if it is only slightly more complex), > then let's not do it. agree committed an added fix in r1500, will update the proposal including it. > >> If we change to a language label of "c" now and then more fully support C++ > > later (which it looks like will happen in the next minor revision), we will > > have to add another language label. > > > > or just an alias to the current one, which is just 1 extra strcasecmp call. > > Again, why even add an extra strcasecmp when it is completely unnecessary. agree, and an extra unneeded strcasecmp removed as well in r1500 Carlo ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
