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

[geiger]

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.

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

>
> 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 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 ?
There must be somekind of solution that doesn't destroy the
SCons build system.

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

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
>