[PD-dev] removing files from externals/build/src
Hans-Christoph Steiner
hans at eds.org
Mon Dec 12 06:18:01 CET 2005
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 at iem.at
>>>> http://lists.puredata.info/listinfo/pd-dev
>>>>
>>>>
>>
>> ______________________________________________________________________
>> __
>> ____
>>
>> ¡El pueblo unido jamás será vencido!
>>
>>
>> _______________________________________________
>> PD-dev mailing list
>> PD-dev at 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
More information about the Pd-dev
mailing list