Is there any reason why it would be bad to put the m_imp.h file from pd into the include path? I guess technically these are not suppossed to be 'public' definitions, yet it seems that many externals need to include this file. Its not stuck in the $PREFIX/include directory.
It also seems that people are using different versions of this file in their externals.
.hc
zen
\
\
\[D[D[D[D
Le lun 28/10/2002 à 19:46, Hans-Christoph Steiner a écrit :
Is there any reason why it would be bad to put the m_imp.h file from pd into the include path? I guess technically these are not suppossed to be 'public' definitions, yet it seems that many externals need to include this file. Its not stuck in the $PREFIX/include directory.
Because PD needs a root directory, usually "/usr/lib/pd", it makes sense to leave everything related to pd in that directory. There's many other headers file, so in the case you'd like to put them under "/usr/include", it'd be better to put them in a "/usr/include/pd" subdir, which is not better than "/usr/lib/pd/include". If you really want to, create a "/usr/include/pd" symbolic link to "/usr/lib/pd/include". The "pd", "pdsend" and "pdreceive" binaries better be in "/usr/bin", since they are executables. -- Marc
Hi all,
It's quite possible that things in m_imp.h will change incompatibly with new versions of Pd... all that is in m_pd.h is in principle stable. So if you write externs using m_imp.h just be prepared for them to have to get re-written now and then...!
cheers Miller
On Mon, Oct 28, 2002 at 08:29:21PM -0500, Marc Lavallée wrote:
Le lun 28/10/2002 à 19:46, Hans-Christoph Steiner a écrit :
Is there any reason why it would be bad to put the m_imp.h file from pd into the include path? I guess technically these are not suppossed to be 'public' definitions, yet it seems that many externals need to include this file. Its not stuck in the $PREFIX/include directory.
Because PD needs a root directory, usually "/usr/lib/pd", it makes sense to leave everything related to pd in that directory. There's many other headers file, so in the case you'd like to put them under "/usr/include", it'd be better to put them in a "/usr/include/pd" subdir, which is not better than "/usr/lib/pd/include". If you really want to, create a "/usr/include/pd" symbolic link to "/usr/lib/pd/include". The "pd", "pdsend" and "pdreceive" binaries better be in "/usr/bin", since they are executables. -- Marc
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On 28 Oct 2002, Marc Lavallée wrote:
Le lun 28/10/2002 à 19:46, Hans-Christoph Steiner a écrit : headers file, so in the case you'd like to put them under "/usr/include", it'd be better to put them in a "/usr/include/pd" subdir, which is not better than "/usr/lib/pd/include".
Compilers are configured so that <pd/foo.h> looks at /usr/include/pd/foo.h, and not /usr/lib/pd/include/foo.h
So I don't know what you mean exactly by "which is not better"...
matju
Le mar 29/10/2002 à 13:47, Mathieu Bouchard a écrit :
Compilers are configured so that <pd/foo.h> looks at /usr/include/pd/foo.h, and not /usr/lib/pd/include/foo.h
So I don't know what you mean exactly by "which is not better"...
In french, I would say "qui n'est pas mieux que".
With "-I/usr/lib/pd/include", ggc looks for header files in "/usr/lib/pd/include". PD is not a development library, it's a software that can be extended with external binary objects.
-- Marc
On 29 Oct 2002, Marc Lavallée wrote:
Le mar 29/10/2002 à 13:47, Mathieu Bouchard a écrit :
Compilers are configured so that <pd/foo.h> looks at /usr/include/pd/foo.h, and not /usr/lib/pd/include/foo.h So I don't know what you mean exactly by "which is not better"...
In french, I would say "qui n'est pas mieux que".
J'ai compris ça, mais j'ai pas compris en quoi ce serait pas mieux.
With "-I/usr/lib/pd/include", ggc looks for header files in "/usr/lib/pd/include".
This fails here because I have not installed PD in /usr.
matju
-
Hans-Christoph Steiner -
Marc Lavallée -
Mathieu Bouchard -
Miller Puckette