On Dec 9, 2005, at 11:06 AM, geiger wrote:
On Fri, 9 Dec 2005, Hans-Christoph Steiner wrote:
Using a namespace solves it in a more complete way. Then people can write objects using the same name and they can all co-exist.
But that is what should be avoided IMO. I do not see the usefulness of two implementations of, lets say prepend, counter or whatever.
I agree that this should be avoided. For example, in Java, which I am using as my namespace example, when they made javax.swing to replace java.awt, the objects that did the same thing were named differently (java.awt.MenuItem --> javax.swing.JMenuItem) even though both could have been called MenuItem and it would have worked. Its clearer to have the objects with different yet related names.
But having a namespace means that when people do make objects of the same name, its much easier to deal with. We have inherited multiple prepends, counters, scales, averages, etc. and people prefer different ones. Its not a good design, but its workable with the namespace.
Maybe one day, we can get to the point where using the same name for the same function in different libraries is actually encouraged, like it is in Java, for example.
Yeah but this is another thing. Most "libraries" in Pd world are not functional entities. They just happen to be written by the same author.
I also think that we should start to push to organize libraries along the lines of functionality rather than author. Then it might make sense, differing from Java, to have objects of the same name in different libs, for example:
[pd/send] [pd/receive] [net/send] [net/receive] [osc/send] [osc/receive]
Then if you have a library, and you want want to use its method of sending and receiving, the object name would be obvious. But this would have the disadvantage of becoming unclear when someone does this:
[import net]
| | [receive foo] [send foo] | |
Then it could be unclear which kind of send/receive is being used. I am undecided about this idea.
The files in externals/build/src end up in the root of the namespace, so if there is an object with a name that is also used in a library, then you would not be able to access the libraries' versions using [import]/[using] object. Currently, [import]/[using] use the path, and since extra is first in the path, no matter what you add to the path, the object directly in extra would always be found first.
this might depend heavily on the implementation of [import]/[using], and I actually think it should be the other way round. If you use import, everything with the same name gets overwritten. Which implementation are you talking about ? I thought there isn't any.
I whipped out a version I called [import] which just takes the library names as arguments and loads them using sys_load_lib() and sys_load_lib_dir(). Its in the extended-RC6 builds. I am guessing your [using] was something like that.
I could leave the files in place in externals/build/src and then just 'rm' the resulting binaries in externals/Makefile, but that seems to be a kludge.
I don't understand how the files in build/src can influence externals/Makefile. Which resulting binaries have to be removed ?
I.e. [prepend]. If there is a [prepend] in "extra", "extra" is first in the path, so that [prepend] will always be opened regardless of the path. That makes it impossible to use the other [prepend]s in separate directories without prepending the directory/library name. So even if I did [import cxc] then [prepend], I would still get the [prepend] in "extra" rather than the one in "extra/cxc".
The [prepend] in "externals/build/src" is the old cyclone one anyway, and the new cyclone one does not compile when dropped into "externals/build/src". The new cyclone one is compatible both with the Max [prepend] and the IEM [prepend].
There must be somekind of solution that doesn't destroy the SCons build system.
I still think having two build systems is a lot of extra work and hassle for zero gain. How many build systems does the linux kernel have? Firefox? Ardour? Audacity? Or Max/MSP for that matter.
Yes, make is whacky and old, but it works and everybody knows the basics of make. Its great that people are experimenting with scons. But I am not interested in experimenting with build systems, I want to experiment with Pd. Someday it might make sense to replace all of the make stuff with some other solution, but until that is proven, I really think we should all agree on one build system and combine efforts so all of us can spend less time on build systems, and more on making Pd better.
I would not delete anything that is not being built by another part of the Makefile, which now builds using the original source, no longer using the #include "../../cxc/prepend.c" links.
Although I think that "make" should be powerful enough to build the externals and Scons is not really needed, the thought of calling "make" from Scons seems to be everything else but a clean solution.
I just suggested that for those who want to use scons instead of maintaining a separate scons build system in parallel to the make system.
Who should want to do that ?
well, my humble opinion, but I do not want to interfere really, so at the end, personally, I don't care,
But your opinion here is important since you originally built the system in question and have a solid understanding of all the issues involved. Thanks for offering it.
Well, I think that the real issues we suffer are social, and I am far from understanding those. For the rest, I don't know more, I just ask myself what is it that it is so hard to build externals. And I fear that we have produced the complexity by ourselves.
I do agree those are issues, but if we can build a system that thrives despite our lack of agreement on those issues, we'll all be better off.
.hc
Cheers, Günter
.hc
Cheers,
Günter
On Fri, 9 Dec 2005, Hans-Christoph Steiner wrote:
First off, thanks for the bug report.
On Dec 7, 2005, at 11:11 PM, ix wrote:
...
as for the deleting, feel free since you created the files in the first place, but keep in mind it will break the completeness of the SCons option if you start removing files...i prefer SCons since it is also used for building devel and actually works for me (see below)
I am not aiming to break things, I am trying to build as much as possible. What is in externals/build/src is only part of what is in externals/. But I am fine with leaving the files in externals/build/src in place, the only ones that need to be removed are the ones with name clashes, like change, prepend, average, scale, etc. They prevent access to the objects of the same name using the namespace (they'd always be found first in the path).
But now there is something better.
ok... bug report then.. :)
(first try)
externals # make Makefile:24: /usr/src/pd/externals/../packages/Makefile.buildlayout: No such file or directory make: *** No rule to make target `/usr/src/pd/externals/../packages/Makefile.buildlayout'. Stop. :
fix: checkout "packages" - since this is a seperate module, perhaps the dep can be moved over since im guessing about 15% of users at most checkout "."..esp with all the weird stuff in it like framestein DLLs and PHP pages
If its a problem, a copy of Makefile.buildlayout can easily be added to the base of externals. I had it there originally, but then removed it since I was changing it a fair amount and it was a pain to keep them in sync. It could even have different values that packages/Makefile.buildlayout if that would helpful. When the other Makefiles are called from packages/Makefile, they are redirected to packages/Makefile anyhow.
This is the layout that I assume in building this: http://puredata.org/docs/developer/devlayout
(second try)
gcc -Wl,-export_dynamic -shared -o "/usr/src/pd/externals/../externals/cxc/ENV.pd_linux" "/usr/src/pd/externals/../externals/cxc/ENV.o" -lc -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../ x86_64-pc-linux-gnu/bin/ld: /usr/src/pd/externals/../externals/cxc/ENV.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/src/pd/externals/../externals/cxc/ENV.o: could not read symbols: Bad value collect2: ld returned 1 exit status
fix: add -fPIC to CFLAGS in /externals/makefile
Oops, -fPIC was there, but this exposed another bug. I wonder why it was compiling fine for me on Linux...
(third try)
it finished...ok. 'make install' wait...why is it configuring more stuff?!?!?! this should have been done in the make step.
I fixed these two problems. Its a work in progress. When you look into the structure of all the code in externals, you'll see that its is far from clean. There are a number of hacky workarounds in externals/Makefile for sure.
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0-beta20051125/../../../../ x86_64-pc-linux-gnu/bin/ld: sendOSC.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC sendOSC.o: could not read symbols: Bad value collect2: ld returned 1 exit status
fix: uh.. i guess go around to all these other makefiles and add -fPIC since it didnt properly inherit the one in /externals/makefile. imo this is the biggest advantage to the SCons system where you have a parent environment, set the flags once, and you _know_ all the subprojects are going to get the same flags and binary/doc location, since they dont even have their own makefiles.
This is also possible and preferred with Makefiles, I tried to take advantage of this as much as possible in the work I just did. Its just that there are a lot of legacy Makefiles around, and many of them don't conform to the Makefile standards. OSCx is not a straightforward build, so I haven't really messed with it at all. It would be nice if it worked on MinGW too.
also, i noticed after various -fPIC failures, it kept going. is it logging these somewhere?
This is a byproduct of calling another build system from the command line (i.e. cd blah/blah && make). It would work properly if it was part of the same Makefile.
(try four)
/bin/sh: /usr/src/pd/externals/../scripts/generate-libdir-metafile.sh: No such file or directory
fix: checkout "scripts" (see try one)
(try five)
more -fPIC stuff...only 'make clean' is not deleting .o files in the subprojects compiled without -fPIC, so i give up for now, to lazy to do some find . -iregex '.*.o' -exec rm {} ; ;)
Again a byproduct of using existing Makefiles. The stuff I have recently written all cleans up more or less properly after itself.
.c....sure, 6 thru 10 once we get these figured out, im happy to try again...
Please try again :)
.hc
__ __ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
__ ____
¡El pueblo unido jamás será vencido!
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
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