>>> 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. >
That's not the point. The point is that this is an end user interface issue. The end user doesn't really care whether it is C, C++, Objective C or any other variation. The end result is that there is a module that needs to be loaded and registered with Gmond and Gmond needs to know if it is a native compiled module or a script language module. 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. This configuration directive is only meant to roughly identify the module class, not to uniquely identify the language it was developed in. 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. >> 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. >> Internally there is no difference in how a C module or a C++ module would be > handled however to avoid confusion later, we would have to treat them > externally as being different. I would suggest that we make the > documentation changes now but leave the "C/C++" language label alone. > > the documentation changes reflect the change in the language tag to "c", > together with the explanation on how to use a C module, do you mean then to > keep the changes in the explanation but keeping all references to the > language > tag even in the documentation as "C/C++"? > Yes. >> I would rather keep the "C/C++" language label so that no configuration file > changes or code changes will be necessary in the next revision when C++ is > more fully supported. > > are you arguing this patch doesn't get committed at all and we just release > this knowing C++ won't work and hoping to have it fixed before anyone finds > out the wrong way? > Yes, again the language tag is an end user issue not necessarily a developer issue. The end user doesn't care what the label actually says and if some developer wants to complain that a label of C/C++ is misleading, fine, it will be fixed in the next revision when full C++ support is there. It doesn't stop the software from working nor does it prevent anybody from using or developing a module. They may not be able to develop a C++ module today, but then changing the language label from C/C++ to C isn't going to help that either. It will just cause unnecessary headaches with the code and configuration as we move forward. Brad ------------------------------------------------------------------------- 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
