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) - $(PROGRAMFILES)/pd/include/pdextended (Pd-extended)
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? Will it stay 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.
Katja
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
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@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
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@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@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
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@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@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at http://lists.puredata.info/listinfo/pd-dev
-
katja -
Miller Puckette -
Roman Haefeli