[PD-dev] including more headers in 'make install'

IOhannes m zmoelnig zmoelnig at iem.at
Thu Aug 5 10:07:29 CEST 2010


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20100805/6c7125da/attachment.bin>


More information about the Pd-dev mailing list