[Xcb] [Bug 80044] New: Deprecate header inclusion of pthread.h and add a define option to disable inclusion of pthread.h

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=80044

          Priority: lowest
            Bug ID: 80044
          Assignee: xcb at lists.freedesktop.org
           Summary: Deprecate header inclusion of pthread.h and add a
                    define option to disable inclusion of pthread.h
        QA Contact: xcb at lists.freedesktop.org
          Severity: normal
    Classification: Unclassified
                OS: All
          Reporter: sstewartgallus00 at mylangara.bc.ca
          Hardware: Other
            Status: NEW
           Version: unspecified
         Component: Library
           Product: XCB

As far as I can tell the only place pthread.h is included or used is in
xcb/xcb.h. Because libraries may have grown to depend upon the inclusion it
will not be possible to simply remove pthread.h from the header file. However,
adding a check for a define (maybe "XCB_NO_INCLUDE_PTHREAD") that disables the
inclusion of pthread.h would be backwards compatible. Then perhaps in the far
flung future the inclusion of pthread.h could be disabled by default.

This issue is important to me because I am interested in statically analysing
my programs and to do so I use a custom set of headers for libc which are
specially annotated. Because statically analysing multithreading is really,
really hard the headers for pthreads have not been implemented yet and so the
static analyser falls back to the system's headers which causes the build to
fail. I would like to be able to disable inclusion of pthread.h and so
statically analyse my program. Of course, I can use an ugly hack to work around
the issue by defining the header guard _PTHREAD_H in my program so the issue is
not at all urgent but eventually in the far flung future I'd like to get rid of
it. Also, statically analysing a big interface such as a GUI is very hard and
not something to bother putting much effort in so this issue is also not
important in that way. I feel this should be done eventually though. I feel
this issue should be solved eventually though.

This issue will eventually make for very, very, slightly faster build times.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20140615/18f35d63/attachment.html>