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
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
Hans-Christoph Steiner wrote:
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.
why don't you want to use ACLs if you want ACLs?
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.
because corelibs IS broken, even without my changes (which tried to fix what was going on)
mf.asdr IOhannes
On Sep 27, 2006, at 4:27 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
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.
why don't you want to use ACLs if you want ACLs?
Because I thought I could trust the Pd developers to ask before the mess with anything that's not theirs. So far, you are really the only violator.
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.
because corelibs IS broken, even without my changes (which tried to fix what was going on)
Check the build logs from the auto-build farm for the past 2 months. I had been building fine on every platform. This is really, really inappropriate. Now its time to do the right thing and reverse your changes.
.hc
Hans-Christoph Steiner wrote:
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.
because corelibs IS broken, even without my changes (which tried to fix what was going on)
Check the build logs from the auto-build farm for the past 2 months. I had been building fine on every platform. This is really, really
i do not doubt that pd-0.39-2 has built fine. however, times are a-changing, like the pd source code, and d_mayer_fft.c is nowadays called d_fft_mayer.c
what i did (try to) do, was to modify your build system in a way, that it could handle both cases. (and the build system has serious problems with this)
mdf.adsr IOhannes
On Oct 4, 2006, at 4:30 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
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.
because corelibs IS broken, even without my changes (which tried to fix what was going on)
Check the build logs from the auto-build farm for the past 2 months. I had been building fine on every platform. This is really, really
i do not doubt that pd-0.39-2 has built fine. however, times are a-changing, like the pd source code, and d_mayer_fft.c is nowadays called d_fft_mayer.c
what i did (try to) do, was to modify your build system in a way, that it could handle both cases. (and the build system has serious problems with this)
Is this urgent? How about waiting until we get the 0.39.2 Pd- extended release out, then we can switch externals/corelibs to work with 0.40 with no need for kludges to support 0.39.2.
.hc
------------------------------------------------------------------------
The arc of history bends towards justice. - Dr. Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
what i did (try to) do, was to modify your build system in a way, that it could handle both cases. (and the build system has serious problems with this)
Is this urgent?
well no, but pd-0.40.1 is out now...
How about waiting until we get the 0.39.2 Pd-extended release out, then we can switch externals/corelibs to work with 0.40 with no need for kludges to support 0.39.2.
i see. i was interested in making both work at the same time, while you were interested in making a release asap. i think both standpoints are valid. (i don't try to prove that "i was right", i just try to explain why i did what i did)
mfga.dsr IOhannes
On Oct 9, 2006, at 12:21 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
what i did (try to) do, was to modify your build system in a way, that it could handle both cases. (and the build system has serious problems with this)
Is this urgent?
well no, but pd-0.40.1 is out now...
How about waiting until we get the 0.39.2 Pd-extended release out, then we can switch externals/corelibs to work with 0.40 with no need for kludges to support 0.39.2.
i see. i was interested in making both work at the same time, while you were interested in making a release asap. i think both standpoints are valid. (i don't try to prove that "i was right", i just try to explain why i did what i did)
I don't think we should waste time on backwards compatibility for the build environment for things like that. Maybe in the future there will be a reason to do that, but for now we have better things to do. If someone wants to build an old version, they can always checked out the sources from CVS.
Miller and I have been talking about how to make Pd-extended and his build systems more in sync. Right now, there are patches to pd/src that are required to make things build. If its possible to build Pd- extended against pd/src without patches, then everything becomes much easier to work with, and issues like these should be easier to deal with. So that I think it the most pressing issue in this regard.
.hc
------------------------------------------------------------------------
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
-
Hans-Christoph Steiner -
IOhannes m zmoelnig