Right now, we have: # gl_MODULE_INDICATOR([modulename]) # defines a C macro indicating the presence of the given module # in a location where it can be used. # | Value | Value | # | in lib/ | in tests/ | # --------------------------------------------+---------+-----------+ # Module present among main modules: | 1 | 1 | # --------------------------------------------+---------+-----------+ # Module present among tests-related modules: | 0 | 1 | # --------------------------------------------+---------+-----------+ # Module not present at all: | 0 | 0 | # --------------------------------------------+---------+-----------+
But I have a condition (namely, test-fclose), where I only want to test a particular behavior of fclose if I know that fflush was replaced at the same level as fclose. That is, if fclose is in lib, but fflush is only in tests, then the test is likely to fail and so I want to compile it out. So here's what I'm thinking: # gl_MODULE_INDICATOR([modulename]) # defines a C macro indicating the presence of the given module # in a location where it can be used. # | Value | Value | # | in lib/ | in tests/ | # --------------------------------------------+---------+-----------+ # Module present among main modules: | 1 | 2 | # --------------------------------------------+---------+-----------+ # Module present among tests-related modules: | 0 | 1 | # --------------------------------------------+---------+-----------+ # Module not present at all: | 0 | 0 | # --------------------------------------------+---------+-----------+ then using: #if GNULIB_FFLUSH == GNULIB_FCLOSE test behavior of fclose on seekable input stream #endif which works if both modules are in lib, or both modules are in tests, but properly skips in libvirt's case where the use of 'getpass' and 'close' pulls fclose but not fflush into lib. Most users just check for non-zero value, and will not be impacted; but with the extra information of lib vs. tests, we can do nicer conditional compilation. Sound reasonable? I'll be posting a full RFC patch shortly, but won't push it until I have feedback. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
