On 2010-08-04 21:29, Hans-Christoph Steiner wrote: > > I've packaged up a bunch of libraries as pd packages, and they rely on > headers besides just m_pd.h. These headers should be included in the > 'make install' so that people can easily build them. I think we should > install these headers into /usr/include: > > m_pd.h > s_stuff.h > m_imp.h > g_canvas.h > g_all_guis.h > > I expect IOhannes to follow with his counterproposal... ;) >
here we go: i'm _strongly_ against installing a header named "s_stuff.h" as /usr/include/s_stuff.h as a name for a public header its close to "header1.h". of course "s_stuff.h" was never meant to be a public header (for a short discussion see [1]) now, i am also _strongly_ with hans, that some of these headers should be made available, in order to be able to build a huge number of non-trivial (and thus probably more interesting) externals. (e.g. a lot of externals are missing in Debian, just because they cannot be built without these headers) in order to not pollute the /usr/include/ directory with "s_stuff.h", "m_imp.h" and "x_header.h" files (and in order to not interfere with the "foo" package, which also provides "s_stuff.h"), i suggest to put them into a separate directory: /usr/include/pd/ or rather: ${prefix}/include/pd/ this is common practice, e.g. see [2] this basically provides full backwards compatibility: until now people had to specify the pd-source path in order to include the private headers; now the pd-"source" simply lives in /usr/include/pd/ rather than /home/zmoelnig/src/pd-0.43-0/src i would also like to provide a pkg-config file, so externals could be build with something like: > cc $(pkg-config --cflags --libs pd) -o foo.pd_linux foo.c mfgsadr IOhannes [1] on the privateness of Pd's header people should be made aware of the fact, that everything outside of "m_pd.h" is not a stable API, but that doesn't mean that the headers must not be distributed. i think it would be enough, if there was a text telling people that "this file describes Pd implementation details which may change in future releases" (quoting s_stuff.h) one could also issue a compiler "#warning", if the file is included without PD_INTERNAL set. [2] http://www.openismus.com/documents/linux/building_libraries/building_libraries.shtml#installingheaders
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev