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 PD-dev@iem.at 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