Hey there,
anyone have a barebones configure.in file for use with PD? How about one for use with FLEXT?
thanks -august.
Ok, to answer, my own question.....after two days of fighting with autoconf and automake, I now have a decent configure setup.
anyway, is there any chance of adding install hooks into the default pd install scripts that put m_imp.h and g_canvas.h into the /usr/local/include directory along with m_pd.h
these two seem to be needed by a number of different externals.
-august.
On Wed, 18 Feb 2004, august wrote:
Hey there,
anyone have a barebones configure.in file for use with PD? How about one for use with FLEXT?
thanks -august.
Hallo,
august hat gesagt: // august wrote:
Ok, to answer, my own question.....after two days of fighting with autoconf and automake, I now have a decent configure setup.
Would you share this?
anyway, is there any chance of adding install hooks into the default pd install scripts that put m_imp.h and g_canvas.h into the /usr/local/include directory along with m_pd.h
these two seem to be needed by a number of different externals.
But they are considered to be a private interface. What should we do?
ciao
to answer, my own question.....after two days of fighting with autoconf and automake, I now have a decent configure setup.
Would you share this?
surely. right now, I'm just making adjustments for darwin. It will come with the new readanysf~
is ./configure, make even possible under windows?
anyway, is there any chance of adding install hooks into the default pd install scripts that put m_imp.h and g_canvas.h into the /usr/local/include directory along with m_pd.h
these two seem to be needed by a number of different externals.
But they are considered to be a private interface. What should we do?
private in what sense? flext uses both of them. and I think I remember some of Olaf's streaming externals using g_canvas.h.
when you do 'make install' in the pd src/ directory...it installs pd under {$prefix}/bin and puts m_pd.h in {$prefix}/include, where {$prefix} is usually /usr/local or /usr. Would it be possible to just send g_canvas.h and m_imp.h along with m_pd.h?
this would prevent someone from allways having to have the pd sources at hand in order to compile externals.
-august.
Hallo, august hat gesagt: // august wrote:
to answer, my own question.....after two days of fighting with autoconf and automake, I now have a decent configure setup.
Would you share this?
surely. right now, I'm just making adjustments for darwin. It will come with the new readanysf~
is ./configure, make even possible under windows?
AFAIK yes, but you need to install several GNU tools.
anyway, is there any chance of adding install hooks into the default pd install scripts that put m_imp.h and g_canvas.h into the /usr/local/include directory along with m_pd.h
these two seem to be needed by a number of different externals.
But they are considered to be a private interface. What should we do?
private in what sense? flext uses both of them. and I think I remember some of Olaf's streaming externals using g_canvas.h.
That doesn't mean they aren't "private". I'm referring to the comment inside g_canvas.h and m_imp.h which reads:
NOTE: this file describes Pd implementation details which may change in future releases. The public (stable) API is in m_pd.h.
So, to repeat my question: How should this be handled?
ciao
AFAIK yes, but you need to install several GNU tools.
right, but is it possible with the mingw gcc compiler? i've tried it once already (about a year ago) with cygwin....but all binaries made that way also need the cygwin environment to run.
That doesn't mean they aren't "private". I'm referring to the comment inside g_canvas.h and m_imp.h which reads:
NOTE: this file describes Pd implementation details which may change in future releases. The public (stable) API is in m_pd.h.
So, to repeat my question: How should this be handled?
I'm not sure I understand this. Externals are using these *.h files already. If they change, those externals will break anyway. So, I'm not sure I understand the difference in keeping them in the pd/src dir or putting them under /usr/local/include ...either way, future changes will break compatability.
-august.
On Fri, 20 Feb 2004, august wrote:
I'm not sure I understand this. Externals are using these *.h files already. If they change, those externals will break anyway. So, I'm not sure I understand the difference in keeping them in the pd/src dir or putting them under /usr/local/include ...either way, future changes will break compatability.
The difference is that you will discourage the use of these files for future externals. To make this work, the ideal solution would be to open up that part of the private interface that is needed, and not all of it.
Guenter
On Fri, Feb 20, 2004 at 04:27:54PM +0100, august wrote:
right, but is it possible with the mingw gcc compiler?
I'd really love to use it. What I'd like even more is cross-compiling externals on Linux for Windows and OSX. Those who master cross-compiling, please tell us how... -- Marc
On Fri, Feb 20, 2004 at 04:27:54PM +0100, august wrote:
right, but is it possible with the mingw gcc compiler?
I'd really love to use it. What I'd like even more is cross-compiling externals on Linux for Windows and OSX. Those who master cross-compiling, please tell us how...
me too. actually, since I am spending a lot of time with it now, what I might be aiming at, is to write an automake/autoconf template for puredata externals, and then expand upon the external-howto to include setup instructions for a) automake build proceedures and b) cross-compile for macosx and win (all under linux if possible)
testing now with updates to my readanysf~ external, it seems to be really easy for MacOSX. I got it to compile rather with some minor adjustments to my configure.ac (swap the suffix with .pd_darwin and such), but am having some problems with LDFLAGS and linking.
anyway, any tips or suggestions would be appreciated.
-august.
ok,
here is a first attempt.
it is just an autoconf/automake setup for the dspobj~.c external that is in doc/6.externs/
http://aug.ment.org/software/dspobj~.tar.gz
first do ./autogen.sh then ./configure
optionally, if you want to do 'make install' after that, configure with opiton: ./configure --bindir=/usr/local/lib/pd/extra
it should be ok for darwin and linux. not sure about other env's.
if you want to use this as a template, put all your sources under './src' and all your headers under './include' the two files you would edit are './src/Makefile.am' and 'configure.ac' the comments should lead you along.
any comments/suggestions? I could use some help with the default CFLAGS for various platforms.
best -august.
On Friday, Feb 20, 2004, at 16:57 America/New_York, Marc Lavallée wrote:
On Fri, Feb 20, 2004 at 04:27:54PM +0100, august wrote:
right, but is it possible with the mingw gcc compiler?
I'd really love to use it. What I'd like even more is cross-compiling externals on Linux for Windows and OSX. Those who master cross-compiling, please tell us how... -- Marc
There were some fits and starts with getting anything to compile with MinGW, but AFAIK, nobody has gotten anything working yet. It would be awesome to have MinGW working and then building a unified, cross-platform build system.
.hc
________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
Actually, i have made some MinGW makefiles for flext and flext-based externals. They are in the cvs. I don't see any difficulties compiling also pure PD externals with MinGW.
best greetings, Thomas
----- Original Message ----- From: "Hans-Christoph Steiner" hans@eds.org To: "Marc Lavallée" odradek@videotron.ca Cc: pd-dev@iem.kug.ac.at Sent: Thursday, February 26, 2004 12:31 AM Subject: Re: [PD-dev] Re: bare bones autoconf/automake scripts for PD
There were some fits and starts with getting anything to compile with MinGW, but AFAIK, nobody has gotten anything working yet. It would be awesome to have MinGW working and then building a unified, cross-platform build system.
.hc
________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli
_______________________________________________ PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
anyway, is there any chance of adding install hooks into the default pd install scripts that put m_imp.h and g_canvas.h into the /usr/local/include directory along with m_pd.h
these two seem to be needed by a number of different externals.
But they are considered to be a private interface. What should we do?
hopefully, it's not c++ these includes ARE needed for any graphical externals, is doing such externals violating privacy?
cheers, sevy
-
august -
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
Marc Lavallée -
Thomas Grill -
Yves Degoyon