hi carmen
Modified Files: Tag: devel_0_39 SConscript Log Message: compiled objs go to /obj/ until make unstall to fix this error: scons: *** Two environments with different actions were specified for the same target: bin/pd-gui File "SConstruct", line 43, in
i intended to put the targets to ./bin, since this is the place, where miller puts his stuff ... when i used autotools and built the stuff to ./src everyone complained ... so it should go to ./bin ... it would be better to figure out, there reason of the error, you experienced ...
t
On Tue, Aug 23, 2005 at 12:18:19PM +0200, Tim Blechmann wrote:
hi carmen
Modified Files: Tag: devel_0_39 SConscript Log Message: compiled objs go to /obj/ until make unstall to fix this error: scons: *** Two environments with different actions were specified for the same target: bin/pd-gui File "SConstruct", line 43, in
i intended to put the targets to ./bin, since this is the place, where miller puts his stuff ... when i used autotools and built the stuff to ./src everyone complained ... so it should go to ./bin ... it would be better to figure out, there reason of the error, you experienced ...
i check out pd source into /usr/local/lib/pd. so the bin dir is the same as the eventual install dir, and the Program()s and SharedLibrary()s share identical filenames with Install(), this is a big no-no in SCons, and also caused problems in autotools...
i check out pd source into /usr/local/lib/pd. so the bin dir is the same as the eventual install dir, and the Program()s and SharedLibrary()s share identical filenames with Install(), this is a big no-no in SCons, and also caused problems in autotools...
well, if you want to place the sources in the fhs, i'd suggest /usr/local/src ...
t
On Wed, Aug 24, 2005 at 01:30:45AM +0200, Tim Blechmann wrote:
i check out pd source into /usr/local/lib/pd. so the bin dir is the same as the eventual install dir, and the Program()s and SharedLibrary()s share identical filenames with Install(), this is a big no-no in SCons, and also caused problems in autotools...
well, if you want to place the sources in the fhs, i'd suggest /usr/local/src ...
.theyre there too, since /usr/local/src/pd is a symlink to /usr/local/lib/pd. i cant be the first one that didnt want 2 copies of all the pd directories..and this surely could affect others who checkout into ~/pd/ or similar and install to the same dir. but youre welcome to do what yuo want, i'll heretofore refer to devel_0_39 as tim_0_39...
.theyre there too, since /usr/local/src/pd is a symlink to /usr/local/lib/pd. i cant be the first one that didnt want 2 copies of all the pd directories..and this surely could affect others who
well, the way you handle that is violating the fhs ... so i guess, it's rather your problem than a general problem ...
checkout into ~/pd/ or similar and install to the same dir. but youre welcome to do what yuo want, i'll heretofore refer to devel_0_39 as tim_0_39...
i don't care, how you call it ... but working on the same branch requires a minimum of communication. i think, i gave you some reasons why i rejected your patches ... you haven't given any good reason, why they should be incorporated ...
best ... tim
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:
1 obj/ exists so why not use it? (or ask sourceforge admin to remove the dir)
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
2.1 even i wouldnt be insane enough to compile binaries right to /usr/bin, which leads to:
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/
3.1 choice of GUI will be in $PATH when launched seperately from server, so lib/pd/bin is a lame duck
.cdr.
best ... tim
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
-
cdr -
ix＠replic.net
-
Tim Blechmann