[Geany] relative paths in project files: is there an option?

[Lex Trotman]

On 30 June 2011 18:42, Stephan Beal <sgbeal at googlemail.com> wrote:
> On Thu, Jun 30, 2011 at 2:29 AM, Lex Trotman <elextr at gmail.com> wrote:
>>
>> Personally I don't see the point, they are all subject to risk of
>> pointing to the wrong place if you move things, relative or absolute.
>> Basically the way the project file stores filenames is no concern of
>> the user,
>
> It damned well is the user's concern when the behaviour causes the wrong
> files to be edited (that's called "data loss" where i come from). i
> edited/broke pages on a live/production web server because i checked out a
> second copy of the site's source tree on the site's machine and started
> editing that second copy (or what i thought was the second copy - geany was
> using the old paths).

I'm sure you had a very embarrassing interview with someone about why
you broke the production server and are very annoyed with yourself,
especially as the full file path shows in the title bar ('aint I a
shtinker rubbing it in...:-) but my point is that no matter how we
store filenames they may point to unexpected places when you move
stuff, and relative files doesn't fix that.  At least absolute always
points to the same place (unless you move it between machines of
course), ../something could be anywhere if things move.

[...]
> i've been programming professionally for going on 20 years now, and i have
> _never_ seen a source tree which has files from _outside_ the source tree
> managed by build/project files within the source tree. Not one single time.
> i challenge you to show me one high-profile (i.e. not only on your hard
> drive) project where such a constellation exist.

Well I top your experience by at least 10 years and I have seen many
project layouts which are forests not single trees, as I noted in a
previous post.  It is a perfectly normal thing for builds to manage.

The problem here is simply the session records rather than anything else.

Partly I think that Geany's project files combine two things that
probably should have been separate,

1. session files which are the concern of the individual programmer and
2. project data which does go with the project tree.

The proper solution would be to separate them, but someone has to do it ...

> In my own software where i have had to deal with this problem, i took a very
> simple approach with which i never had any unexpected problems/behaviours:
> a) The project file's directory (where we load it from) is the virtual root.
> b) Paths to files under that root are stored relative.
> c) Paths to outside that root are stored absolute.
> This is easy to do in the project-file-writing code with a function call
> like (normalized=NormalizePath(theFilename)), and to un-do when loading the
> project file.

As Matthew pointed out there is a use-case (and a common one from past
user input) where project files don't go in the tree, they live in the
users ~/projects. In this case the sources are probably not under your
project file so relative is irrelevant, its back to absolute.

Its actually we big system people who tend to have the need to keep
project data in the vcs, and who have the control over the projects to
be able to do it.  Can you imagine approaching Linus asking to put a
Geany project file in the Linux vcs? or any GNU project? or ...  so in
all these cases the project file is user local outside the tree.

And when the project file is outside the tree then absolute makes sense.

Cheers
Lex