[PD-dev] removing files from externals/build/src

[Hans-Christoph Steiner]

On Dec 9, 2005, at 4:04 AM, geiger wrote:

>
> HI,
>
> I think it is not necessary to delete the files in the src/ folder.
> It seems to be a cosmetic change only.
>
> From the point of view of the CVS, the nameclash problem
> should not exist, so its not a good argument for deleting these files.
>
> If the nameclash problem really exists, I propose to delete that in
> the first place. (We already solved the prepend problem, didn't we ?)

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.  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.

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.

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 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.

> 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.

.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!