>>> On 4/2/2008 at 2:43 PM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > On Wed, Apr 02, 2008 at 10:08:04AM -0600, Brad Nicholes wrote: >> >>> On 4/1/2008 at 10:28 PM, in message <[EMAIL PROTECTED]>, Carlo >> Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: >> > >> > ok, but then if the application also has a need to access the metric data >> > (like gmond) then we will end up including gm_protocol.h twice, and that >> > will lead to redefined symbols (that headers is generated by rpcgen and >> > might not have protection against multiple inclusion) >> >> No, rpcgen does the right thing in the header to make sure that it doesn't > get included multiple time. >> >> #ifndef _GM_PROCOTOL_H_RPCGEN >> #define _GM_PROCOTOL_H_RPCGEN >> >> ... >> >> #endif > > that is implementation dependent and not required (RFC1832), so not all > implementations of rpcgen do that (indeed it might be assumed to be > discouraged as rpcgen is meant to generate plain C code and therefore > implicitly not require a preprocessor) > > as I explained before, cygwin's at least doesn't and will therefore result > in a broken build. > > if you want to rely in this implementation specific behaviour then the > gm_protocol.x file should be processed and the result committed instead > of relying on rpcgen to do that at compile time, but will be IMHO much > simpler > just to do the header change I suggested and avoid committing generated > files > which will then result in maintenance headaches later when they get modified > without changing the source first and regardless of the warnings about > not doing that which are to be found on its header. >
It sounds like if the cygwin version of rpcgen is not producing the appropriate #ifndef, then there is a high potential for breaking the cygwin build at anytime anyway. All that needs to happen is the unintentional include of gm_protocol.h in any of the source files and things would continue to work correctly on all other platforms except cygwin. In reality there should be no reason for an application to ever include gm_metric.h in addition to ganglia.h anyway. gm_metric.h only contains definitions that are specific to a metric module. There is nothing in gm_metric.h that an application would require for any purpose. That is why I split out gm_val.h and gm_msg.h so that those definitions could be included by both ganglia.h and gm_metric.h without having to force one or the other to include unnecessary definitions. The only time that a double inclusion of gm_protocol.h might happen is if a module decided to include ganglia.h directly. I don't see any need for a module to do this because all of the libganglia functions are too high level for a module. >> >> Metric modules would include gm_metric.h to get just the metric module >> > related stuff. Metric modules don't really need all of the libganglia >> > prototypes. >> > >> > but since they are most likely to use at least the debug and error message >> > prototypes it shouldn't be a problem to include it. >> >> gm_metric.h already includes gm_msg.h so there shouldn't be any problem > there either. > > corrected for mod_example in r1193 then : > > Index: mod_example.c > =================================================================== > --- mod_example.c (revision 1192) > +++ mod_example.c (revision 1193) > @@ -31,7 +31,6 @@ > > ***************************************************************************** > */ > > #include <gm_metric.h> > -#include <ganglia.h> /* Only need for the debug and error message prototypes > */ > #include <stdio.h> > #include <stdlib.h> > #include <time.h> > > still see no reason why not to export the libganglia interface to all metric > modules through "ganglia.h", specially considering it solves real problems > and > would make sense to extend the libganglia API later to support the modular > interface (as there is no such thing as a libgmond yet). > The only reason is because it is unnecessary and doesn't really solve any problem. An application has everything it needs to access metric data and deal with interfacing with gmond through the ganglia.h definitions. There is nothing that an application needs in gm_metric.h so there should be no danger of multiply including gm_protocol.h in an application. The headers have been reworked so that all of the functions that a module might need from libganglia are already available by including gm_metric.h. Everything else that ganglia.h exposes is too high level for a metric module and therefore unnecessary. I just don't see any need to tie both ganglia.h and gm_metric.h together. These headers are meant for completely different implementations. Brad ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
