[PD-dev] Pd include paths on Windows

[Miller Puckette]

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 <msp at ucsd.edu> 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
> >> Pd-dev at lists.iem.at
> >> http://lists.puredata.info/listinfo/pd-dev
> >
> >
> > _______________________________________________
> > Pd-dev mailing list
> > Pd-dev at lists.iem.at
> > http://lists.puredata.info/listinfo/pd-dev
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> http://lists.puredata.info/listinfo/pd-dev