[PD-dev] corelibs, build system

[Hans-Christoph Steiner]

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