GetRelativePathFrom()


#1

I’m not sure I like the decision that is being made in this function (where ‘the only common bit is the root’); I think that as long as the files are indeed on the same drive, it should always return a relative path.

Example: This behaves as expected…

File a(T("C:/Test1/Sub"));
File b(T("C:/Test1/file.txt"));

String s = b.getRelativePathFrom(a);
// s == "..\file.txt"

This, on the other hand, produces unsatisfactory results:

File a(T("C:/Test1/Sub"));
File b(T("C:/Test2/file.txt"));

String s = b.getRelativePathFrom(a);
// expected s == "..\..\Test2\file.txt"
// recieved s == "C:\Test2\file.txt"

Any chance of tweaking this?


#2

…that doesn’t feel right to me somehow. What are the circumstances that made you query its behaviour?


#3

I’m making a project builder to generate makefiles/VCProjects/etc … part of that is building a list of files and using paths relative to a specified project folder. Naturally it is designed to be executed on the machine which the project is used on, but i was unsettled to see that a bunch of files had literal paths when there was really no reason to.

Basically, with the current function definition, if a file is on the same volume, yet the lowest directory is different, it will not return a relative path. I just can’t understand why that would be considered an acceptable behaviour .

To illustrate, lets say a user has ticked a setting in a juce app to store links to files as ‘relative’; they know that their ‘project’ file is on the same drive as these files; they are learned enough to understand the concept of relative links and are comfortable with the arrangement.

Now consider that, for some reason, they need to move the files (either to a subfolder on the same drive, or onto a different drive). They take care to ensure that the folders containing projects and linked files maintain their relationship in the drive’s folder structure.

Why should they not expect such a procedure to work successfully? :slight_smile:


#4

Ok, that’s convincingly argued! So just changing it to use the same code as it uses for unix platforms should work.


#5

Splendid :smiley:


#6

that’s true… and should be for every other piece of code around there… ehehe

:smiley:


#7

I’m just curious… Why, when cmake already does that?
(http://www.cmake.org)


#8

internal tools for work. that’s just how we like it :slight_smile:


#9

Ok, It’s just that I’m a firm believer in not re-inventing the wheel… :wink: