[PD-dev] compile pd with cygwin
I've found some hints in here: http://lists.puredata.info/pipermail/pd-cvs/2004-10/001658.html and it resolves many problems (Thanks to Thomas Grill), why those modifications have been removed? I've built many modules but compilation has stopped with an error on s_midi.c, there are indefined references to "sys_putmidibyte" and other stuff from s_stuff.h, why s_stuff.h isn't included? Here is the begining of s_midi.c I've modified: #include "m_pd.h" #include "s_stuff.h" #include "m_imp.h" #if defined(UNISTD) || defined (_CYGWIN_) #include #include #ifdef HAVE_BSTRING_H #include #endif #endif #ifdef MSW #include #include #include #include #endif #include #include #include snip and here is the begining of the successfully compiled s_file.c I've also modified: #include "m_pd.h" #include "s_stuff.h" #include #include #include #include #if defined(UNIX) || defined(__CYGWIN__) #include #include #include #include #include #include #endif #ifdef MSW #include #include #endif int sys_defeatrt; t_symbol *sys_flags = &s_; void sys_doflags( void); #if defined(UNIX) || defined(__CYGWIN__) static char *sys_prefbuf; ---snip--- Thanks for any hint. ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] autotools magic for externals?
moin Claude,
On 2007-11-29 20:10:19, Claude Heiland-Allen
<[EMAIL PROTECTED]> appears to have written:
> So, is there a set of macros I can drop into my acinclude.m4 that
> provide a nice auto-n00b-friendly environment as a base for creating a
> configure.ac and a Makefile.am for a Pd external that requires some
> libraries?
I don't think so. I ask occasionally on the list if there are any m4
programmers lurking about to help setting up something like you
describe, but so far no one has bitten, and I haven't got around to
learning m4 myself yet.
> I've been trying to use autotools (autoconf and friends) to build pdlua,
> but have ended up in a world of pain and deleted my experiments out of
> frustration. I tried to understand the system used in
> CVS/externals/moocow/, but the wizardry was somewhat beyond me. Even
> more so with the Gem system.
I can't speak for gem's build system, but the autotools conventions in
externals/moocow/* are most definitely to be considered *hacks* (rather
than "wizardry" ;-) ... for example in 'readdir':
configure.ac or configure.in:
+ the stuff under "how to hack automake EXEEXT conventions" says it
all: automake-1.4 handles the $(EXEEXT) make variable differently than
automake-1.9, but I'm not sure when exactly the change occurred. The
big idea is that pd externals are built with automake "_PROGRAMS"
targets, but they also need to be installed with a ".pd_whatever"
extension. So I use EXEEXT to tell automake what that extension is
+ the lines:
>> PD_OBJECT_EXTERNALS="readdir${buildext}"
>> AC_SUBST(PD_OBJECT_EXTERNALS)
just substitute @PD_OBJECT_EXTERNALS@ into Makefile from Makefile.am.
You don't need it or anything like it if you know what all your sources
and targets are: I sometimes use PD_OBJECT_EXTERNALS to differentiate
between library and single-object builds (e.g. in pdstring/).
+ the directory arguments & checks should be self explanatory
+ the stuff under "machine-dependent flags" is borrowed (mostly) from
pd's own configure.in, and can probably be left untouched.
config/ subdir:
+ I put autotools-specific stuff here, to avoid cluttering up other
distribution root or source directories
src/ subdir:
+ The guts: set EXEEXT and build externals as pdexterns_PROGRAMS
targets (which is valid since configure.ac did AC_SUBST(pdexternsdir)).
+ pd-style compiler flags are gathered into AM_CPPFLAGS, AM_CFLAGS, and
readdir_LDFLAGS (if you have other libraries to link to, put them in
myprog_LDADD, e.g. "readdir_LDADD = -lfoo -lbar").
... in general, there's probably a lot of junk hanging around in the
various files that you don't need, but (probably) won't hurt ;-)
Certainly ignore and/or delete any rules about $(PODS), unless you're
generating README files out of README.pod in perl's pod format.
If you have specific difficulties and/or questions about my autotools
hacks, don't hesitate to ask -- I freely admit that they're ugly and
cryptic, but they're actually quite adaptable...
marmosets,
Bryan
--
Bryan Jurish "There is *always* one more bug."
[EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] autotools magic for externals?
Claude Heiland-Allen wrote: > Hi all, > > I've been trying to use autotools (autoconf and friends) to build pdlua, > but have ended up in a world of pain and deleted my experiments out of > frustration. I tried to understand the system used in > CVS/externals/moocow/, but the wizardry was somewhat beyond me. Even > more so with the Gem system. is the autoconf-system in zexy any more help? it is way simpler than the one i use in Gem. mfga.dr IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] autotools magic for externals?
Hi all, I've been trying to use autotools (autoconf and friends) to build pdlua, but have ended up in a world of pain and deleted my experiments out of frustration. I tried to understand the system used in CVS/externals/moocow/, but the wizardry was somewhat beyond me. Even more so with the Gem system. So, is there a set of macros I can drop into my acinclude.m4 that provide a nice auto-n00b-friendly environment as a base for creating a configure.ac and a Makefile.am for a Pd external that requires some libraries? In other news regarding pdlua, I created a Makefile.static for those that want to compile Lua into the external statically. Currently only in the development version, soon to be pdlua-0.3 once I've added enough new features to merit a release. Thanks for any input, Claude -- http://claudiusmaximus.goto10.org ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] SQLite for PD v0.0
http://puredata.info/Members/mjmogo/ Done, check it out at the above link. Mike On Nov 27, 2007 11:50 PM, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote: > > What's the address for the ftp server? You could also post it on > puredata.info, just make an account. > > .hc > > On Nov 27, 2007, at 1:14 PM, Mike McGonagle wrote: > > Hello all, > > Ok, I got some preliminary things to test. As far as I can tell, > everything works using the message input method. There are still some issues > to resolve for the 'text' widget entry method. > As it still contains the Amagamated version of SQLite, the archive that I > have is about 800K. I posted the stuff on an FTP server. The login info > is... > > > User: fsr > Password: puredata > > There is a darwin external for PPC in the archive. You don't need to have > a database, as the test program will allow you to create one, and add a > table, and some data. > > > Mike > > > > -- > Peace may sound simple—one beautiful word— but it requires everything we > have, every quality, every strength, every dream, every high ideal. > —Yehudi Menuhin (1916–1999), musician > ___ > PD-dev mailing list > PD-dev@iem.at > http://lists.puredata.info/listinfo/pd-dev > > > > > > > > There is no way to peace, peace is the way. -A.J. Muste > > > -- Peace may sound simple—one beautiful word— but it requires everything we have, every quality, every strength, every dream, every high ideal. —Yehudi Menuhin (1916–1999), musician ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-1841002 ] Add format string error checking, and fix related errors
Patches item #1841002, was opened at 2007-11-29 09:11 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1841002&group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Russell Bryant (russellbryant) >Assigned to: Miller Puckette (millerpuckette) Summary: Add format string error checking, and fix related errors Initial Comment: This patch adds format string error checking for bug(), error(), verbose(), and pd_error(). It also fixes the errors in the pd core that were pointed out by this change. There are some other functions that take printf style format strings that would benefit from this same change, but I wanted to address pieces of it at a time. -- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-11-29 13:15 Message: Logged In: YES user_id=27104 Originator: NO Looks like the right thing to do, and seems very likely to do any harm. I'm going to try it in Pd-extended. The only concern I can think of is whether the __attribute__ stuff causes any problems when building with MSVC, since some people still build Pd with MSVC. This site seems to claim it does not: http://ocliteracy.com/techtips/gnu-c-attributes.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1841002&group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] Tcl/Tk8.5 on debian-testing-i386
Hey all, Just an FYI, I installed tcl-8.5-dev and tk-8.5-dev on the Debian/ testing build server. Let's hope this is an easy transition. It introduces lots of good stuff, like anti-aliasing and truetype fonts on GNU/Linux, much improved graphics performance on Mac OS X, and probably more stuff. .hc "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity."-John Gilmore ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] [ pure-data-Patches-1841002 ] Add format string error checking, and fix related errors
Patches item #1841002, was opened at 2007-11-29 08:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1841002&group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Russell Bryant (russellbryant) Assigned to: Nobody/Anonymous (nobody) Summary: Add format string error checking, and fix related errors Initial Comment: This patch adds format string error checking for bug(), error(), verbose(), and pd_error(). It also fixes the errors in the pd core that were pointed out by this change. There are some other functions that take printf style format strings that would benefit from this same change, but I wanted to address pieces of it at a time. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1841002&group_id=55736 ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[PD-dev] cygwin build (was:Re: [PD] pdlua compiling on mac)
Hans-Christoph Steiner a écrit : > > If you want to build Pd and externals with Cygwin, you'll have to add > some stuff to the build system. No one has done it before. Pd-extended > is built with MinGW/msys on Windows. I've built pd and some externals with mingw, it needs makefile.mingw for pd, but it would be nice if the main makefile would do the job... Anyway, I'm more interested about using cygwin for some reasons, it's easy to install it and all dependances, and we can use Qt/X11 inside > On Nov 28, 2007, at 7:20 PM, Patrice Colet wrote: >> makefile.dependencies >> d_osc.c:39:2: #error No byte order defined >> d_array.c:527:2: #error No byte order defined >> make: *** [makefile.dependencies] Erreur 1 I've just added #include into d-osc.c and d_array.c to resolve this because this is where BYTE_ORDER is defined. Now I get another error, API_DEFSTRING from s_main.c:359 isn't declared, I could find out how to resolve this and juste removed the variable to go further... and got another error: statbuf isn't declared as well. It seems that the build system misses something like "#ifdef CYGWIN" somewhere, but I couldn't figure out what to do with it. ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] hex loader
Mathieu Bouchard wrote:
> On Wed, 28 Nov 2007, IOhannes m zmoelnig wrote:
>
>> right, i found out that hexloader does a bad job when trying to load
>> patches. this part of the hexloader is obviously still experimental.
>> what it does is to register a dummy class for an abstraction which it
>> thinks it should handle.
>
> Why do you need dummy classes?
because i don't know how to do it otherwise.
i would be glad for advice on how to do it in a better way.
e.g. i still don't understand how to use pd_objectmaker.
what i am currently doing is:
if hexloader is called for an object that needs hexmangling and it finds
a relevant abstraction, it registers a class with the object-name.
when this object is instantiated, a setup-function provided by hexloader
is called, which then instantiates the abstraction, by calling "
binbuf_evalfile()" (and all the rest i copied from m_class.c:542..552)
this works fine, as long as no abstractions are within abstractions
(that is the problem patrick experienced).
i think the problem is, that Pd has some recursion-prevention mechanism
("tryingalready"), that hinders the instantiation of abstractions with
externals.
probably i should have a look how [dyn] handles this.
fgm,asdr
IOhannes
___
PD-dev mailing list
PD-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] [PD] hex loader
Mathieu Bouchard wrote: > On Wed, 28 Nov 2007, IOhannes m zmoelnig wrote: > >> i don't like matju's suggestion to provide an API, > > Ideally, hexloader should be merged into the core and the API would be a > single function shared by the loader and the parts of the internals that > do the same thing as the hexloader does (the symbol mangler). yes and no. the hexloader is a bit less strict when it comes to filename mangling (as certain characters are allowed in filenames but not in c-functionnames); one yould of course use the strictest character set, but i think it adds to readability (in your console (or file-browser, if you insist); not in the patch) to use a larger set of characters if possible. > > I'm not really advocating that an external exposes an API otherwise than > as pd objects and methods... but then, this is also what Gem need to do > if some externals are not linked directly into Gem... so it must not be > that ugly. GridFlow will also have to do it eventually. I just think > that doing it for one function is a waste. ok, so we are have the same idea here. i have no problem with a "Gem external" (or "GF external" or whatever) to depend on another external (Gem, or GF, or whatever), because that's what they are: extensions to a certain external and not extensions to Pd. i think most of the loaders aim to be extensions to Pd rather than extensions of the hexloader. but anyhow, i think we agree. > Anyway, because virtually the same code is already in the core, it makes > sense to have that shared function in the core, so the issue of linking > to an external should be moot. > >> as this would require to have hexloader be loaded before all other >> externals that rely on that API. > > Not if the linker knows about it. (The problem is how to tell the linker > about it) well yes; but _i_ don't know how to tell the linker about it :-) > >> what might be a better solution is to tell Pd to try to load a >> different class instead (kind of recursively calling the loading stuff). > > I don't understand. very simple, let's have an example: let's assume we have a pdlua-class ">~" within a file "0x3e0x7e.lua" the loaders loaded are: odlua, hexloader A. (this is how it is happening now) pd is told to create [>~] which it doesn't know about yet. it calls sys_load_lib(c, ">~") which it turn calls all the loader: 1. it runs sys_do_loadlib, which tries to load the external ">~.l_i386", and fails. 2. it runs pdlua, which tries to load ">~.pdlua" and fails. 3. it runs hexloader, which tries to load "0x3e0x7e.l_i386" and "0x3e0x7e.pd", and fails B: this is how i think it might work. pd is told to create [>~] which it doesn't know about yet. it calls sys_load_lib(c, ">~") which it turn calls all the loader: 1. it runs sys_do_loadlib, which tries to load the external ">~.l_i386", and fails. 2. it runs pdlua, which tries to fin ">~.pdlua" and fails. 3. it runs hexloader, which tries to load "0x3e0x7e.l_i386" and "0x3e0x7e.pd", and fails 4. hexloader now calls sys_load_lib(c, "0x3e0x7e") 4.1. it runs sys_do_loadlib, which tries to load the external "0x3e0x7e.l_i386", and fails. 4.2. it runs pdlua, which tries to load "0x3e0x7e.pdlua" and succeeds. btw, all this slows down loading of abstractions considerably. fgmasdr. IOhannes ___ PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
