Indeed - thanks for pointing that out... cheers M
On Sun, Dec 06, 2015 at 02:38:27PM +0100, katja wrote: > Hi, > > Roman, thanks for providing the script and Miller thanks for > distributing Pd with installer. > > I'm aware that Pd can be copied / installed on any location of choice, > but to keep things manageable Makefile.pdlibbuilder only searches > preferred paths as proposed by 'official' Pd distributions. Windows > has whitespace in those paths anyhow, which are interpreted by GNU > make (and maybe other scripting languages) as list element separators. > Meaning you can't use make's built-in functions if some processing > must be done on those paths. This greatly adds to the puzzle that a > portable build system is. One of the tricks a developer can use is to > cd into $(PROGRAMFILES) and process relative paths names from there. > Now you can imagine my surprise when I came across 'Pure Data'. > > Katja > > On Sun, Dec 6, 2015 at 1:06 AM, Miller Puckette <[email protected]> wrote: > > Thanks for spotting this... I think if there are already installations in > > $(PROGRAMFILES)/pd we should stick to that. I'll go on and try to change it > > in Roman's script :) > > > > M > > > > On Sun, Dec 06, 2015 at 12:56:34AM +0100, Roman Haefeli wrote: > >> On Sat, 2015-12-05 at 23:17 +0100, katja wrote: > >> > Hello, > >> > > >> > In Makefile.pdlibbuilder I'm trying to define some standard Pd include > >> > paths. On Windows with MinGW this used to be (if I'm not mistaken): > >> > > >> > - $(PROGRAMFILES)/pd/src (vanilla Pd) > >> > >> Before there was an installer, Pd for Windows was available as zip > >> archive and as such could be installed anywhere. It might make sense to > >> use that as an include path, but Pd cannot safely be assumed to be > >> installed there. Being able to install it without admin privileges (in > >> other words: not to the path above) was mentioned as an advantage of the > >> archive (some called it the 'portable' version). > >> > >> > - $(PROGRAMFILES)/pd/include/pdextended (Pd-extended) > >> > >> Yes, the installer proposes this path. > >> > >> > Now I've installed Pd 0.46-7 with the experimental new installer from > >> > Miller's downloads, for which must be set: > >> > > >> > - $(PROGRAMFILES)/Pure Data/src > >> > > >> > Is this path experimental too? > >> > >> I am to blame for this. I set that as the default in the installer > >> script and Miller obviously didn't change it. I had the user in mind > >> rather than the developer. I chose it because 'Pure Data' is the > >> canonical name of the software. > >> > >> > Will it stay like this? > >> > >> I believe it is marked experimental exactly for the reason to be able to > >> address issues like this. > >> > >> > I would hope > >> > that at least the whitespace could be taken out of the 'Pure Data' > >> > component so you could define relative paths without spaces. > >> > >> I might not clearly see what you mean (relative to what?), but are > >> whitespaces still an issue? $(PROGRAMFILES) resolves to a path with > >> spaces on the majority of the Windows systems in the world anyway (often > >> to 'C:\Program Files\'). > >> > >> Roman > > > > > > > >> _______________________________________________ > >> Pd-dev mailing list > >> [email protected] > >> http://lists.puredata.info/listinfo/pd-dev > > > > > > _______________________________________________ > > Pd-dev mailing list > > [email protected] > > http://lists.puredata.info/listinfo/pd-dev > > _______________________________________________ > Pd-dev mailing list > [email protected] > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
