IOhannes, PLEASE PLEASE PLEASE PLEASE PLEASE!!!!!!!!! ASK BEFORE YOU
MESS WITH SOMEONE ELSE'S STUFF!!!!!!! This is one of the most basic
and fundamental rules of working together, and you are violating this
rule again and again, though we ask you not to! That is why we have
this list. I am getting really tired of you breaking the stuff that
I spent a lot of time setting up. I really don't want to have to use
ACLs in CVS, but you are leaving me no other choice.
corelibs is a section that I set up and only I have worked on so
far. You
did not ask at all. d_mayer_fft.c is the name of the file in
0.39.2. You have broken compilation for Pd-extended.
- please revert all changes to the docs/developer section
- please revert all changes to externals/corelibs
Let's start over and do this right.
.hc
On Sep 26, 2006, at 5:02 AM, IOhannes m zmoelnig wrote:
corelibs is currently broken due to a renaming of pd/src/
d_mayer_fft.c to pd/src/d_fft_mayer.c
while i updated the corelibs/generate.sh script to handle this, it
still does not really work with the autobuild-system.
the reason for this is (imo) the very complicated stacking of
Makefiles (externals/Makefile vs. externals/corelibs/Makefile)
which makes it impossible for a make-noob like me, to generate
the .c files in the makefile while calling make in /externals (it
does work fine when i do just "make" in externals/corelibs.
the reason is, that CORELIBS_OBJECTS is evaluated before the files
are generated (which would result in NO objects, since there should
be no .c files before generation)
a simple solution would be, to call "make -c corelibs/ generate"
and then "make -C corelibs/" from the externals/Makefile.
obviously this does not work, since externals/corelibs/Makefile has
no logic and instead uses externals/Makefile with the "corelibs"
target (which would make my idea quite recursive).
then again there is the horror of touching externals/Makefile at
all: this huge file makes it quite hard/impossible to work on / fix
several targets at the same time.
e.g. yesterday i first worked on corelibs, then noticed that zexy
won't build as it should, so i had to revert all the changes i had
done to the Makefile (since it didn't yet work properly) so i could
start fixing the zexy-build (which i understand better, and which i
was pretty sure to be able to fix).
so i ask this again: would it not be better to have the build-logic
for each directory in a separate Makefile (which could be edited
separately)?
these Makefile could make use of a generic(!) Makefile which (e.g.)
lives in externals/
this generic Makefile MUST NOT have any intelligence about the
separate destination targets (e.g. no different logic for building
"corelibs" or "hid"; just a generic "build" target); if such
intelligence is needed, it should live in the projects subdirectory
(externals/corelibs/Makefile)
i would also like to know the exact reason for the pwd-magic (i
just never ever needed such thing in any makefile i wrote, so i'm
curious)
mfg.asdr
IOhannes
_______________________________________________
PD-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an
idea, which an individual may exclusively possess as long as he keeps
it to himself; but the moment it is divulged, it forces itself into
the possession of everyone, and the receiver cannot dispossess
himself of it. - Thomas Jefferson
_______________________________________________
PD-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
