* Mark Wielaard ([email protected]) wrote: > On Wed, 2011-04-13 at 11:38 -0400, Mathieu Desnoyers wrote: > > * Mark Wielaard ([email protected]) wrote: > > > I have just been using the following configure check: > > > > > > AC_CHECK_HEADER([sys/sdt.h], [SDT_H_FOUND='yes'], > > > [SDT_H_FOUND='no'; > > > AC_MSG_ERROR([systemtap support needs sys/sdt.h > > > header])]) > > > > > > Which you can adapt to your needs with/without error message, including > > > an test to see if it fully works for your environment. > > > > Thanks for the hint, but adding this test in the UST build system don't > > really make sense, because both systemtap and UST don't have dependency > > on each other, and thus the build order between the two packages is not > > fixed. So the detection should be done when the UST header is being > > included into an application rather than at UST configuration time. And > > I don't want to require all applications that want to use tracepoint to > > use autoconf neither. > > Sure autoconf is optional. But if you want UST tracepoints to be > recognized by other consumers that use SDT probe points, then just > depending on the availability of sys/sdt.h in UST seems to make the most > sense. Note that sys/sdt.h is kind of independent from systemtap proper. > It can be installed independently from the systemtap stap translator or > runtime. And it is only a build dependency, not a runtime dependency. > All consumers just parse the notes section to get the addresses to place > their probes and extract the arguments. There is even a binutils bfd > extractor now.
So we seem to have two choices here: either add a dependency on the package providing sdt.h in UST, or copy sdt.h into UST (it's public domain, so the licensing permits it). For the package dependency: I'd need to know: 1 - which package provide sdt.h. 2 - which distributions provide it. 3 - what the dependencies of the package are. 4 - which architectures are supported by this package. we must keep in mind that UST targets many distributions and many architectures. For the sdt.h copy: we could certainly ship it into UST too. It might be much, much easier. I would put it in ust/sdt.h so we don't overwrite the SystemTAP header when we install it. We'd have to be careful about changes to this header though, because we can end up with two entirely different versions. The #ifndef _SYS_SDT_H would take care of handling multiple inclusion of the ust and systemtap sdt.h header incarnations. One way to handle this versioning problem would be to define a header "version" at the beginning of sdt.h in both SystemTAP and UST incarnations: #define _THIS_SDT_H_VERSION 3 #if (!defined(_SDT_H_VERSION) || _SDT_H_VERSION < _THIS_SDT_H_VERSION) either #undef all sdt.h macros /* rest of the sdt.h header */ or /* this scheme would require that we only append to the SDT macros, * never change the macros per se */ #ifndef each macro name #define macro #endif #endif #undef _SDT_H_VERSION #define _SDT_H_VERSION _THIS_SDT_H_VERSION #undef _THIS_SDT_H_VERSION Thoughts ? Thanks, Mathieu > > Cheers, > > Mark > -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
