why i rejected your patches ... you haven't given any good reason, why they should be incorporated ...
well the main reason im being pedantic here is because a bug that doesnt affect YOU is no reason to revert a fix (unless you own the branch..which is why ive renamed it ;) but this is a good time to discuss pd's sordid dir structure in general:
right ... this bug doesn't affect me, actually it doesn't affect anyone, who is using a directory structure that doesn't interfere with the fhs...
1 obj/ exists so why not use it? (or ask sourceforge admin to remove the dir)
we _use_ it, but for the objects only ... ever had a look at miller's tarballs?
2 src/../bin/ could likely be the install dir (esp on OSX/Windoze) and thus cause SCons errors or causing MSVC to think the binaries are up to date when theyre not, similar things have even happened with autotools..its an endless source of build issues
well, why install it, if the files are already there?
3 lets kill the pd dir (remember redhat annoyingly installing half its stuff into /opt! apache did away with its own structure and xorg did away with /usr/X11R6 in 7.0..) and put bin in /usr/bin, docs in /usr/share/doc/pd, externs in /usr/lib/pd/
i'm trying to stick to miller's directory structure as close as possible... it's not clean either ... files shouldn't be in ./lib, but in ./share, but i don't want to have any annoying bug reports, just because the wrong files are run (i've experienced them "devel doesn't load my externals", when putting the binaries in ./src rather than ./bin)
t