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

geiger geiger at xdv.org
Fri Dec 9 10:04:54 CET 2005


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 ?)

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.

well, my humble opinion, but I do not want to interfere really, so at
the end, personally, I don't care,

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
>




More information about the Pd-dev mailing list