Hello, I thought I'd leave a thought on this thread. We very much appreciate libraries that keep their headers segregated, even if they come with clean names. All our internal stuff is also segregated in such a manner.
It helps in a number of small practical ways, for example to find project dependencies you can very easily grep for "#include\s+<$libname/" and find all what's pointing to this or that component. Something mundane on which you probably don't want to spend too much brain power... For the case of zmq, for example, I did arrange for the haders to land into <zmq/...> anyways. Slightly deviant from your practice, but easier to work with in our setup. We do this with all the libraries we can, when we have control over the downstream dependencies. Also, note that if you have a header a.h inside zmq/ you can slightly alter the CPPFLAGS and the files that say #include <a.h> still work fine, whereas the opposite is quite a bit harder :-) Luca On 15/11/11 9:04 PM, Martin Sustrik wrote: > Hi Phil, > >>> 2. What's the rationale for moving the header? I prefer writing #include >>> <zmq.h> to #include<zmq/zmq.h> personally. >> The primary rational is to provide a dedicated location in which developers >> can inspect the headers and view the api. One of the first things I do when >> working with libraries is turn to the include area and view those headers. >> >> One cannot read the headers if one does not know what they are. Providing >> a private directory for them is a convenience to developers. >> >> When I look at my include area, I see: >> >> $ ls -1 z* >> >> zclock.h >> zconf.h >> zctx.h >> zfile.h >> zframe.h >> zhash.h >> zlib.h >> zlist.h >> zloop.h >> zmq.h >> zmq.hpp >> zmq_utils.h >> zmsg.h >> zsocket.h >> zsockopt.h >> zstr.h >> zthread.h >> >> It takes a keen eye to discern that zlib.h is not part of your libraries. >> Worse, >> suppose one day you wish to add a header called 'zlib.h'? Having to worry >> about >> name collisions across the universe of headers is unreasonable with so many >> packages >> out there these days. > Ok, right. It's messy. However, note that the only header from the list > that belongs to core 0MQ project is zmq.h. > > The rest are from czmq project so I guess the fix should be done there. > What you would get is a single header file in /usr/local/include (zmq.h) > and a directory czmq that would contain the remaining czmq-related headers. > > Placing a single zmq.h file into a subdirectory seems to be an over-kill > IMO. > > Thoughts? > Martin > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
