FYI: I created a release branch called branch-v0-39-2-extended last night following the instructions here:
http://puredata.org/docs/developer/Branching
I will be making commits to all sections of that branch in order to fix things and get things working. Hopefully, these changes can make it into MAIN too. (So far I have committed pdp and pidip fixes)
.hc
------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
Hans-Christoph Steiner wrote:
FYI: I created a release branch called branch-v0-39-2-extended last night following the instructions here:
http://puredata.org/docs/developer/Branching
I will be making commits to all sections of that branch in order to fix things and get things working. Hopefully, these changes can make it into MAIN too. (So far I have committed pdp and pidip fixes)
fine. one quick note: i have just (today) added moocow's pdstring objects to the "flatspace" library, so that they can be included in pd-extended. obviously i was late; but i really would love them to be added. so it would be nice if you could add this addition to your commits.
mf.asr IOhannes
On Dec 11, 2006, at 11:45 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
FYI: I created a release branch called branch-v0-39-2-extended last night following the instructions here: http://puredata.org/docs/developer/Branching I will be making commits to all sections of that branch in order to fix things and get things working. Hopefully, these changes can make it into MAIN too. (So far I have committed pdp and pidip fixes)
fine. one quick note: i have just (today) added moocow's pdstring objects to the "flatspace" library, so that they can be included in pd- extended. obviously i was late; but i really would love them to be added. so it would be nice if you could add this addition to your commits.
Yup, its in there.
.hc
------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hans-Christoph Steiner wrote:
On Dec 11, 2006, at 11:45 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
FYI: I created a release branch called branch-v0-39-2-extended last night following the instructions here: http://puredata.org/docs/developer/Branching I will be making commits to all sections of that branch in order to fix things and get things working. Hopefully, these changes can make it into MAIN too. (So far I have committed pdp and pidip fixes)
fine. one quick note: i have just (today) added moocow's pdstring objects to the "flatspace" library, so that they can be included in pd-extended. obviously i was late; but i really would love them to be added. so it would be nice if you could add this addition to your commits.
Yup, its in there.
cool thanks.
mfa.sdr IOhannes
morning folks,
On 2006-12-12 10:05:50, IOhannes m zmoelnig zmoelnig@iem.at appears to have written:
Hans-Christoph Steiner wrote:
On Dec 11, 2006, at 11:45 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote: i have just (today) added moocow's pdstring objects to the "flatspace" library, so that they can be included in pd-extended.
Yup, its in there.
glad that the pd-string is useful to someone besides myself ;-) also, thanks for thinking of them in your current endeavors, and apologies for lurker-like behavior on my part recently...
does this mean i have been lax in maintaining my externals on sf? is there some document somewhere i should read regarding how to get the buggers built automagically? i admit i've never paid much attention to the build/ subdir, and scons rather eludes me (too lazy to learn python), but i do feel capable of maintaining my own code, rather than foisting yet another burden on you guys. i'll probably be spending some time with cvs again in the near future, once i get a replacement for my stolen laptop (*grrr*)...
marmosets, Bryan / moocow
On Dec 12, 2006, at 6:27 AM, Bryan Jurish wrote:
morning folks,
On 2006-12-12 10:05:50, IOhannes m zmoelnig zmoelnig@iem.at appears to have written:
Hans-Christoph Steiner wrote:
On Dec 11, 2006, at 11:45 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote: i have just (today) added moocow's pdstring objects to the "flatspace" library, so that they can be included in pd- extended.
Yup, its in there.
glad that the pd-string is useful to someone besides myself ;-) also, thanks for thinking of them in your current endeavors, and apologies for lurker-like behavior on my part recently...
does this mean i have been lax in maintaining my externals on sf? is there some document somewhere i should read regarding how to get the buggers built automagically? i admit i've never paid much attention to the build/ subdir, and scons rather eludes me (too lazy to learn python), but i do feel capable of maintaining my own code, rather than foisting yet another burden on you guys. i'll probably be spending some time with cvs again in the near future, once i get a replacement for my stolen laptop (*grrr*)...
If you want to use the Pd-extended build system, its currently just a plain Makefile. No fancy ./configure or automake stuff, (tho it would be nice if there was).
Basically, just copy the "template" section in externals/Makefile and edit it so that your code compiles and is installed into the right places. I tried briefly with your code, but there is was stuff done by auto tools.
.hc
------------------------------------------------------------------------
I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler
morning Hans, morning list,
On 2006-12-13 07:04:37, Hans-Christoph Steiner hans@eds.org appears to have written:
If you want to use the Pd-extended build system, its currently just a plain Makefile. No fancy ./configure or automake stuff, (tho it would be nice if there was).
Basically, just copy the "template" section in externals/Makefile and edit it so that your code compiles and is installed into the right places. I tried briefly with your code, but there is was stuff done by auto tools.
yup, i use a hacked Makefile.am for my pd externals, because the builtin targets (install, uninstall, dist, clean, etc.) are so darned handy. still, there's no reason why i couldn't pack in a default makefile as well. many thanks for the tip -- i'll try adding some default makefiles (and probably config.h etc.) when compiling on the new machine once I get it...
marmosets, Bryan
On Dec 13, 2006, at 3:41 AM, Bryan Jurish wrote:
morning Hans, morning list,
On 2006-12-13 07:04:37, Hans-Christoph Steiner hans@eds.org appears to have written:
If you want to use the Pd-extended build system, its currently just a plain Makefile. No fancy ./configure or automake stuff, (tho it would be nice if there was).
Basically, just copy the "template" section in externals/Makefile and edit it so that your code compiles and is installed into the right places. I tried briefly with your code, but there is was stuff done by auto tools.
yup, i use a hacked Makefile.am for my pd externals, because the builtin targets (install, uninstall, dist, clean, etc.) are so darned handy. still, there's no reason why i couldn't pack in a default makefile as well. many thanks for the tip -- i'll try adding some default makefiles (and probably config.h etc.) when compiling on the new machine once I get it...
Perhaps an even better approach would be to help me figure out how to do everything with autoconf and automake, replacing externals/Makefile.
.hc
------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem.
On 2006-12-14 01:34:07, Hans-Christoph Steiner hans@eds.org appears to have written:
On Dec 13, 2006, at 3:41 AM, Bryan Jurish wrote:
yup, i use a hacked Makefile.am for my pd externals, because the builtin targets (install, uninstall, dist, clean, etc.) are so darned handy. still, there's no reason why i couldn't pack in a default makefile as well.
Perhaps an even better approach would be to help me figure out how to do everything with autoconf and automake, replacing externals/Makefile.
eek.
well, i've now read the README and had a look at the developer docs on puredata.org, but i'm still a bit baffled as to how the whole build system hangs together (haven't spent much time perusing the actual makefiles yet).
as to using the autotools for building pd externals, using my current conventions, I'd estimate that it's actually more effort (for the developer) than tailoring the 'template' section of externals/Makefile: basically, what I do (well, the relevant bits anyways) for a new external library (see pdstring or gfsm for examples) is the following [might not be very helpful, but i had to refresh my memory, so here it is]:
in configure.in [now officially "configure.ac", but I'm lazy]: + add configure arguments using AC_ARG_WITH: --with-pd-dir=DIR * default=/usr/local/pd * sets $(pddir) and $(pddocdir), for installation --with-pd-extdir=DIR * default=$PD_DIR/externs * sets $(pdextternsdir), for installation --with-pd-include=DIR * default=$PD_DIR/src * sets $(pdincludedir), for compiler flags + sanity check for m_pd.h with AC_CHECK_HEADER + (do whatever checks are necessary for the external: gfsm, etc.) + set machine-dependent compiler flags and PDEXT (copied from pd's own configure.in) + if the package supports multiple-external-library and single-file build modes, add arguments for selection and set a variable (i use PD_OBJECT_EXTERNALS) that gets used in src/Makefile.am to set pdexterns_PROGRAMS ~ there's actually no such argument in pdstring, but there could be
in src/Makefile.am: + major ugly nasty hack: set EXEEXT=.$(PDEXT) ~ so I can use *_PROGRAMS targets to for externals + easy stuff (similar to Makefile 'template' tailoring): ~ set pdexterns_PROGRAMS (pdexterns_EXTRA_PROGRAMS) to the externals I (might) want to build ~ set pdexterns_DATA to any abstractions I want to install ~ set pddoc_DATA to any help patches I want to install ~ set myextern_SOURCES to the actual source files for 'mylibrary' ~ adopt compiler and linker flags into AM_CPPFLAGS, AM_CFLAGS, AM_CXXFLAGS, mylibrary_LDFLAGS ~ add distributed pd patches to EXTRA_DIST
... i also use a config/ subdir (AC_CONFIG_AUX_DIR) to keep the autotools files out of the package root directory, but that's more hindrance than help for a template-like system, and shouldn't really make any difference at all.
that having been said, i think the "right" way to do it would actually be to write a small common set of m4 macros that developers could just call from configure.(in|ac) and use in Makefile.am, analagous to AM_INIT_AUTOMAKE() or AM_PROG_LIBTOOL(); call it something like 'PUREDATA_BUILD_INIT()', which could take care of all of the configure.(in|ac) manipulations, as well as the various FLAGS variables. Heck, maybe we could even use libtool directly...
setting EXEEXT=.$(PDEXT) is very very ugly, i admit. the "right" thing to do here (im(ns)ho) would really be just to tweak the automake $(whatever_)PROGRAMS expansion code into something like $(whatever_)PDEXTERNS. The default install dir for _PDEXTERNS targets could then be set to $(pdexternsdir) [vs. $(bindir) for _PROGRAMS], so just setting "PDEXTERNS = any2string string2any" would suffice. Similarly for documentation ("PDDOCS"?), abstractions ("PDPATCHES"?), etc. A default configure.in could even be made available which performs all of the basic configuration (AC_PROG_CC, AM_INIT_AUTOMAKE, PUREDATA_BUILD_INIT), for those who don't need/want additional autoconf checks.
getting all of that to work properly and transparently would be pretty heavy on the m4 coding side, and I've only ever used m4 in a very rudimentary capacity (stupid string substitution). it would have advantages (centralized administration of compiler flags for known architectures, conventional default directories, install, uninstall, dist, distcheck targets, etc. etc.), but sounds like more than i can personally chew at the moment [cf. signature] ;-)
marmosets, Bryan
-
Bryan Jurish -
Hans-Christoph Steiner -
IOhannes m zmoelnig