Make - use relative paths

[dimitre]

not meant to work with spaces in project name
only when you are using a system you can't modify the username and it has spaces.
so make only work with relative paths, and if your project located inside OF folder everything works.

PS: Tested only on macOS, OF was installed in a folder called "of 3"

[artificiel]

the realpath was added to make the parsing "more accurate" — not sure what the inaccuracies might have been, but still... reverting to a prior state raises questions.

that being said, Make is notoriously anti-space (see https://stackoverflow.com/questions/61592591/makefiles-with-spaces-in-filepath#comment108950849_61592591 -- madScientist is maintainer of Make). without knowing what might be affected by the changes, not sure "working around" for what amounts to a partial solution is worth the risks (and/or the time required to harness tests guaranteeing there are no side-effects).

[dimitre]

Let's test it in different environments and find out. I have some different Linux setups to test later today.
Do you have access to some windows box?

I don't even need this in my setup, but I think it is important to have OF working on teaching environments.

[artificiel]

of course anything that helps a bit is good, but my point is more to put in perspective the calories spent on the build system.

anyhow, without being a perfect technique, I find that escaping spaces tend to survive better the scenarios of appending path strings in scripts than trying to quote them (as the quotes must be carefully maintained each time an operation is performed).

starting with such as

OF_ROOT=`realpath ../../.. | sed 's/ /\\ /g'` 

maybe there's a way to have spaces work while keeping realpath in the loop.

(no windows unfortunately here)

[dimitre]

So I thought it was some kind of subtle dry humor in double quotes "more accurate", but it seems you really have a point in using having realpath always present in Makefiles (not a native english speaker here, so I get lost on language subtleties).
I would love to know the reasoning behind it, to get up to date with your mentation process

[artificiel]

ah! but the "more accurate" is in the git blame!

[dimitre]

Thanks!

[dimitre]

@ofTheo @artificiel I can't see any downsides to using relative paths in Make.
It will solve the classic issue of a computer with a space in username. like /Users/tim hecker/openFrameworks

[artificiel]

yes I think it's 2 things: the spaces in path is separated from the absolute/relative concept.

relative sounds fine and will work even if the "higher" path contains spaces, and the user keeps projects inside OF folder. that covers a lot, but if the projects are outside OF folder, then it depends, spaces might still break things. but i mentioned above I was wondering why the introduction of realpath was made (as it creates "hardwired" projects) and the notice is that it is more "accurate". I don't know what the inaccuracies could have been? maybe there are other positive sanitizing side effects? but it's worth a try. maybe a flag in PG to toggle absolute vs relative?

for the spaces, I was referring to the Make maintainer who says it's a hard combat (unfortunately the link above is broken) and that there is no official support http://savannah.gnu.org/bugs/?712 but if one is determined to try to make it work, escaping spaces is found to be a more resilient approach than quoting the whole path.

[dimitre]

Yes it is separated
spaces will continue to be an issue inside OF folder organization, which is easily addressable by the user.
But it will address issues arising from /Users/谢 谢/ofw
issues from the past (I've seen some) arised from education environments, or when people used computers without admin access.
to separate and tangential issues are: using less absolute paths in the core, and addressing windows encoding issues with multiple languages (there is a PR ready for this one)

[dimitre]

@ofTheo I think this one is good to go
Any opinion on this one?
I think scripts/linux/examplesMakeTemplate.sh file can be removed