There is a glitch in any2string that is stopping Pd-extended from building:
------------------------------
Message: 2 Date: Sun, 29 Jul 2007 07:09:49 -0400 (EDT) From: pd@debian-testing-powerpc.idmi.poly.edu (pd) Subject: [PD-cvs] autobuild: pd-extended debian-testing-powerpc 2007-07-29 06.27.18 To: pd-cvs@iem.at Message-ID: 20070729110950.1146B4219@debian-testing-powerpc.idmi.poly.edu
cc -Wl,-export_dynamic -shared -o "/home/pd/auto-build/pd-extended/ externals/build/src/any2list.pd_linux" "/home/pd/auto-build/pd- extended/externals/build/src/any2list.o" -lm -lc \ `test -f /home/pd/auto-build/pd-extended/externals/build/src/ any2list.libs && cat /home/pd/auto-build/pd-extended/externals/build/ src/any2list.libs` \ `test -f /home/pd/auto-build/pd-extended/externals/build/src/../ linux/any2list.libs && \ cat /home/pd/auto-build/pd-extended/externals/build/src/../linux/ any2list.libs` chmod a-x "/home/pd/auto-build/pd-extended/externals/build/src/ any2list.pd_linux" strip --strip-unneeded -R .note -R .comment /home/pd/auto-build/pd- extended/externals/build/src/any2list.pd_linux rm -f -- /home/pd/auto-build/pd-extended/externals/build/src/any2list.o cc -DPD -O2 -pipe -fsigned-char -mpowerpc-gfxopt -I/home/pd/auto- build/pd-extended/pd/src -Wall -W -ggdb -DUNIX -Dunix -fPIC -o "/home/ pd/auto-build/pd-extended/externals/build/src/any2string.o" -c "/home/ pd/auto-build/pd-extended/externals/build/src/any2string.c" In file included from /home/pd/auto-build/pd-extended/externals/build/ src/any2string.c:1: /home/pd/auto-build/pd-extended/externals/build/src/../../moocow/ pdstring/src/any2string.c:76: error: expected ‘,’ or ‘;’ before ‘PACKAGE_VERSION’ /home/pd/auto-build/pd-extended/externals/build/src/../../moocow/ pdstring/src/any2string.c: In function ‘any2string_new’: /home/pd/auto-build/pd-extended/externals/build/src/../../moocow/ pdstring/src/any2string.c:151: warning: unused parameter ‘sel’ make[2]: *** [/home/pd/auto-build/pd-extended/externals/build/src/ any2string.o] Error 1 make[2]: Leaving directory `/home/pd/auto-build/pd-extended/externals' make[1]: *** [externals_install] Error 2 make[1]: Leaving directory `/home/pd/auto-build/pd-extended/packages' make: *** [install] Error 2 upload specs linux_make . deb Uploading /home/pd/auto-build/pd-extended/packages/linux_make/./Pd*.deb ls: /home/pd/auto-build/pd-extended/packages/linux_make/./Pd*.deb: No such file or directory
------------------------------------------------------------------------ ----
¡El pueblo unido jamás será vencido!
Hans-Christoph Steiner wrote:
There is a glitch in any2string that is stopping Pd-extended from building:
i fixed that yesterday.
and it is rather a glitch in the assumptions the externals/build/src/ makes than in the pdstring, which just builds perfectly.
mf.adsr IOhannes
moin again,
On 2007-07-31 09:43:21, IOhannes m zmoelnig zmoelnig@iem.at appears to have written:
thanks!
and it is rather a glitch in the assumptions the externals/build/src/ makes than in the pdstring, which just builds perfectly.
i don't wish to agitate slumbering canines, but it would be nice if the externals/build system and pdstring (also gfsm, readdir, etc) played nicely with one another. I keep putting off writing default externals/build-compatibile makefiles, basically because I think there's got to be a "better" way to do it, most likely involving automake|autoconf. any m4 hackers on the list these days?
also, i seem to recall hearing or reading recently something to the effect that "multiple-object libraries are deprecated" -- is there any knock-down drag-out argument why this should be so?
marmosets, Bryan
Bryan Jurish wrote:
plenty of them :-)
anyhow, i have started a wiki at http://puredata.info/Members/zmoelnig/pdcon07/PdAgenda where i collect ideas on what i would love to have discussed on the pdcon07 (fooing up a build-system that i don't use by modifying and (build-)testing my own external being one of them)
please contribute (even if you don't attend)
i thought they died out last century, followed by a great bio-diversity of scons, cmakers and antlers.
mfga.dfrt IOhannes
On Tue, 31 Jul 2007, IOhannes m zmoelnig wrote:
... and rakes.
but so far I don't want to spend time working around the features of scons, which is why I upgraded to autoconf; never mind the AutoWTF ( http://artengine.ca/matju/pics/autowtf.png ), I still don't have much faith in any other build tools so far.
"multiple-object libraries are deprecated"
... only according to pd-extended.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Jul 31, 2007, at 12:56 AM, Bryan Jurish wrote:
I make no claims that what exists is a great system. But it is far better than anything else that exists. If someone wants to replace the whole thing that would be great, as long as they first do it outside of the existing system to prove it works, then it could be integrated into the main builds. There also has to be a solid, long term commitment from some devs to maintain it.
I would love to hand over all that to someone, but I really do not want to spend more time working around new build issues, that's why I am insistent that it is created outside of the mainstream builds first.
As for maintaining your code in the existing Pd-extended build system, no one is obligated. But if you add your code/library to it, then you need to maintain what you have setup, IMHO. If you want your code to be distributed and work with Pd-extended, then you'll want to maintain it within the Pd-extended build system.
.hc
------------------------------------------------------------------------ ----
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
moin all,
warning: idle pontifications follow ;-)
On 2007-07-31 20:04:34, Hans-Christoph Steiner hans@eds.org appears to have written:
... I still haven't heard a solid argument for this one ... sorry if i missed it on the list previously -- anything in particular I should search the archives for? I realize that autoloading only currently works (in vanilla pd at least) for object-named externals (which is why I try to build a "dummy" library object into my libraries (a la johannes' dummy [zexy] object))... are there other instabilities or issues i'm not aware of? Even if it's just a matter of makefile pattern matching, I could understand it ... (although I wouldn't actually qualify makefile pattern matching as a "knock-down drag-out" argument)...
I make no claims that what exists is a great system. But it is far better than anything else that exists.
I freely admit that the pd-extended build architecture is certainly a working and unified system, and as such is indeed far preferable to the veritable chaos of disparate conventions otherwise employed by the various external authors (myself included) -- everybody seems to pretty much roll their own. Indeed, the externals/build directory has saved me personally a good deal of wailing and gnashing of teeth, for which i am eternally (> 3.4e+38 temporal units of your choice) grateful.
I'm also pretty happy with the pure-make approach in build/src: I certainly prefer it to SCons or other make alternatives.
Aye. There's the rub. Not having the time myself to dive into an alternative, I should probably just keep my big mouth shut, however... I haven't, so...
There are various reasons (including historical) for the various build conventions floating about in externals/, and the pd-extended build has to co-exist somehow with all of them (at least, with all of those which feed into pd-extended)... and it would seem to me that a hierarchical build procedure (e.g. recursive descent with make) would be preferable to the "glob-and-guess" technique in externals/build/src, and to the monolithic externals/Makefile: it would allow library builds (to which I'm partial) as well as leaving maintainance of pd-extended build support entirely within the domain of the individual externals' maintainers... but that's just wishful thinking... I'll try and see how to weasel my conventions into externals/Makefile without breaking anything ;-)
Agreed. By the same token, though, it should be clear which bits have been set up by whom -- just another reason for hierarchical builds, really...
marmosets, Bryan
On Jul 31, 2007, at 4:21 PM, Bryan Jurish wrote:
This has been discussed quite a bit on the lists and at the Pd Con 1. Here's the basic synopsis with the problems with the multi-class- single-file libs:
1) no way to sort out name conflicts 2) every object is loaded regardless of whether it's used. 3) does not work with namespaces (i.e. [moocow/any2string])
Plus once libdir format is more flushed out, there will also be embedded help, examples, etc. and a common library format regardless of which language the objects are written in (Pd, C, etc.)
Yes, the current build system isn't elegant. I would love to see it replaced by something better. I would really hate to see it semi- replaced by something that doesn't get completed.
No argument here, someone just needs to commit to the work.
.hc
------------------------------------------------------------------------ ----
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Hans-Christoph Steiner wrote:
Yes, the current build system isn't elegant. I would love to see it replaced by something better.
it is not about elegance nor about "being better". it is all about maintenance.
there are currently at least 4 different ways to build zexy: - my build system (autoconf/make) - pd-extended (which currently uses my build system) - build/ - scons
i simply cannot keep track whether my changes to my code affect all of these systems. i am happy if it compiles with mine.
fmgasd.r IOhannes
http://puredata.info/Members/zmoelnig/pdcon07/BuildIntegration
On Aug 1, 2007, at 1:30 AM, IOhannes m zmoelnig wrote:
I couldn't agree more, we should have one build system for everything. Right now, the only functional option for that is the current Pd-extended build system.
.hc
------------------------------------------------------------------------ ----
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
moin all,
On 2007-08-02 04:28:44, Hans-Christoph Steiner hans@eds.org appears to have written:
Right. So what we need (im(ns)ho) is a least-common-denominator sort of way to dispatch to variant build systems.
Agreed. Hence my long-intended stay-up-late-hacking session yesterday, during which I believe to have snuck (most of) my externals into the pd-extended system. The tricks I used rely on the pd-extended build using GNU make, but it looks like there are a number of other GNU-isms in externals/Makefile, so I feel safe there (feel free to object, of course). I wound up (mostly) just delegating the build from the "moocow" targets in externals/Makefile to conventional targets ("build", "install", "clean") in externals/moocow/extended/Makefile, which in turn just call (./autogen.sh; ./configure; make; make install) with (hopefully) suitable arguments. The same basic technique could be made to work more systematically, *especially* if GNU make is ensured ($(eval $(call ...)) is your friend!)
One thing I'm uncertain of (never having built the whole pd-extended from scratch) is what is supposed to live in the $(pd_src) variable; or rather, where "m_pd.h" is supposed to live in relation to $(pd_src)/. I've gone with the assumption that m_pd.h lives in $(pd_src) directly. Please let me know if I should use e.g. $(pd_src)/src instead.
http://puredata.info/Members/zmoelnig/pdcon07/BuildIntegration
I've added a few thoughts to this page -- I hope you don't mind. In particular, one of the major itches I've had when compiling a new pd version or installing on a new machine is the lack of unified conventions for handling machine-specific optimization flags ("-march=" and friends). I think that any specification for a new|old|hybrid build architecture should take this into account, at best without requiring users to edit a file that itself lives in CVS. Thomas Grill's flext system is one way to handle this sort of thing, but I'd most like to see it handled by environment variables (e.g. CFLAGS, or maybe PD_CFLAGS) and make's "?=" and "+=" operators... again, feel free to object and to kick my wiki paragraph into /dev/null if you think that's where it belongs...
Of course, any CFLAGS passed down from the "global" build options might get lost, clobbered, or just ignored by local builds: that should be allowed, but I'd like to motion for the establishment of some convention here.
marmosets, Bryan
On Aug 2, 2007, at 4:12 PM, Bryan Jurish wrote:
The global variables $(pd_src) are defined in packages/ Makefile.buildlayout:
pd_src = $(cvs_root_dir)/pd
so m_pd.h is in $(pd_src)/src
We should use a standard method for this kind of thing, like autoconf. This would another advantage of a unified build system. This mostly works with Pd-extended now, but it could be handled much better.
.hc
------------------------------------------------------------------------ ----
All information should be free. - the hacker ethic
moin moin,
On 2007-08-03 08:23:14, Hans-Christoph Steiner hans@eds.org appears to have written:
ack. i saw that my additions had broken the pd-extended daily build yesterday, so i removed 'moocow' from LIB_TARGETS again. I'll test extensively here before adding it again. many apologies!
[snip]
in fact, one of my major beefs with autoconf is that the AC_PROG_CC macro insists on (re-)setting CFLAGS (on gcc systems, it gets re-set to "-g -O2"). I work around it by caching and re-instantiating the value before and after AC_PROC_CC... so even with autoconf, we would need either (a) hacks or (b) explicit variable name semantics conventions, if we want (as I would like) to be able to lug machine-local flags around in the environment.
marmosets, Bryan
On Aug 3, 2007, at 2:04 AM, Bryan Jurish wrote:
Don't worry about removing it unless you don't have time to fix it within a few days. Then I'd start to nag ;) We've all broken the nightly builds before, you're not the first :D. It's there to make our lives easier, not harder.
I think it would make a lot of sense for the existing Pd-extended build system to be replaced with a proper automake/autoconf system that was used throughout. Anyone know of any example projects with many modules that are handled using autotools?
.hc
------------------------------------------------------------------------ ----
¡El pueblo unido jamás será vencido!
moin,
On 2007-08-04 03:25:22, Hans-Christoph Steiner hans@eds.org appears to have written:
thanks -- i've gotten the whole shamozzle to build here now, and put moocow back in LIB_TARGETS; I'll check the logs again tomorrow to see if it's breaking anywhere, although a veritable plethora of (||true)s ought to ensure that doesn't happen this time ;-)
i know i've seen recursive autotools projects, but none jumps to mind immediately... maybe apache? ardour? xorg?
at any rate, the relevant autoconf macro appears to be AC_CONFIG_SUBDIRS. in automake, the relevant variable is SUBDIRS, which is allowed to be a macro substitution (SUBDIRS=@SUBDIRS_WE_REALLY_WANT@)
marmosets, Bryan
moin moin,
On 2007-08-01 05:05:27, Hans-Christoph Steiner hans@eds.org appears to have written:
(2) is certainly true. That's the whole point of multi-object libraries, isn't it? I think it can even be advantage, if a large shared codebase is used by multiple objects in a library (take gfsm as an example: a full static build takes almost 3 times the memory of a dynamic one: memory is cheap, but that's no excuse for inefficiency!)
Frankly, I just don't believe (1) or (3) is actually the case. I'll grant that multi-object libraries don't get you either (1) or (3) "for free" (as the filesystem does), i.e. without changes to the pd core, but they're most definitely solveable problems. (OK... I admit I don't really want to solve them either, but I'd prefer to hunker down on fixing the "real" problems than to see Pd go the way of java just because it seems like the path of least resistance)...
This is all great, but I don't think any of it actually conflicts with multi-object libraries -- you'd just have a multilib as an external in its own directory: so what?
marmosets, Bryan
On Fri, 3 Aug 2007, Bryan Jurish wrote:
(2) is not true, because dlopen uses mmap, and mmap uses lazy loading for parts that are "loaded" in read-only mode. This is regardless of RTLD_LAZY vs RTLD_NOW: those flags are about symbol resolution; actual inclusion of the file into the process's memory is done using CPU-level virtual memory and the kernel's disk-cache.
(What I say is the case on at least Linux and OSX; can't quite speak for MS)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
moin all,
sorry, my bad -- probably just due to a missing HAVE_CONFIG_H preprocessor define ... I'll add a fix when I get home this evening...
marmosets, Bryan
On 2007-07-31 02:33:42, Hans-Christoph Steiner hans@eds.org appears to have written: