Hi, all,
i recently got into the unusual (for me) situation that i have the same project checked out twice on the same machine - one for our "production/live" environment and the one where i hack. My geany project file uses (i found out accidentally after i hosed a production web page) absolute paths in the project files. This makes the files essentially worthless in terms of committing them to source control, since they can only be used on machines with the exact same dir structure (and they can't be used twice on the same machine).
Is there an option to enable the use of relative paths in the project files?
(To be clear: i'm not blaming geany for hosing the web page. i shouldn't be developing directly on that system, but am forced to for company-internal logistical reasons. But i am growling at geany for opening a project file under ~/myproject and having it edit pages under /var/www/...).
On Tue, 28 Jun 2011 19:28:12 +0200 Stephan Beal sgbeal@googlemail.com wrote:
Is there an option to enable the use of relative paths in the project files?
From the look of get_session_file_string(), no.
I remember such a discussion taking place some time ago. It was not so straightforward - for example, what about the files not under the project directory? Store /var/log/foo as [../]{N times}/var/log/foo? Or, for files in a nearby directory, break them each time you copy the project and open it from the new location? (Well the last operation is dangerous currently - you'll be working on the previous files.)
It would have been nice to store anything under the project directory as relative, and everything outside as absolute, but some of the developers opposed even to that, can't remember why. There was also talk about storing each filename as both relative and absolute, and try to open the relative first. I thought that was implemented, but don't see it anywhere. So, for now, what you see in the title is what you get.
On Tue, Jun 28, 2011 at 7:52 PM, Dimitar Zhekov dimitar.zhekov@gmail.comwrote:
I remember such a discussion taking place some time ago. It was not so straightforward - for example, what about the files not under the project directory?
There shouldn't _be_ any files not under the project dir, at least not managed by the project management tool. IDEs are almost exclusively used for working on source-control-based projects, and every source tree is rooted in one directory.
Store /var/log/foo as [../]{N times}/var/log/foo? Or, for files in a nearby directory, break them each time you copy the project and open it from the new location? (Well the last operation is dangerous currently - you'll be working on the previous files.)
That's what happened to me. The file i edited happened to be in the "opened" list in the project file, and the "wrong" one was opened when i checked out my second copy. It was just bad luck that /var/www happens to belong to my user account on that machine (so that i can check out the website from svn - we don't actually edit anything under that tree). If i had been on a system i didn't maintain myself, the error would have been caught when i tried to save (and it couldn't write).
i understand and appreciate the subtle problems involved, as i've had the same issues before in my own software, but it can (and has) been done. Use the project file's directory as the root and simply strip that part from all paths in the project file. Project files are, almost without exception, stored in the top level of the source tree. If they're not, they should be. It's just good manners and its where new project members/casual viewers expect to find them. Just like the 'configure' script and makefile.
The current behaviour fails miserably if i rename/move a directory or end up on a machine with a different user name (i.e. different path to my project file). Geany won't be able to find anything. If the paths are relative, such a change is transparent to the user.
It would have been nice to store anything under the project directory
as relative, and everything outside as absolute, but some of the developers opposed even to that, can't remember why. There was also talk about storing each filename as both relative and absolute, and try to open the relative first. I thought that was implemented, but don't see it anywhere. So, for now, what you see in the title is what you get.
i really appreciate the detailed response. :)
On 06/28/11 11:17, Stephan Beal wrote:
done. Use the project file's directory as the root and simply strip that part from all paths in the project file. Project files are, almost without exception, stored in the top level of the source tree. If they're not, they should be. It's just good manners and its where new project members/casual viewers expect to find them. Just like the 'configure' script and makefile.
Myself, I keep all of my Geany project files in a top-level ~/Projects directory and below that a sub-directory for each project's source tree. I also add 'configure' and 'Makefile's to my VCS ignore file as to not check them in (assuming they're auto-generated by Autotools or whatever).
From my observations, it's quite rare to see developers' personal "project files" in a project's source tree or checked into VCS. Even a Geany-specific project like geany-plugins doesn't contain a single project file in its repository (from a quick `find' for *.geany).
My $0.02
Cheers, Matthew Brush
From my observations, it's quite rare to see developers' personal "project files" in a project's source tree or checked into VCS. Even a Geany-specific project like geany-plugins doesn't contain a single project file in its repository (from a quick `find' for *.geany).
Yes, agree, its only been useful for projects that define non-default build commands or settings. Then they need to be stored with the project to ensure that the developer uses the correct commands when they open the project.
Cheers Lex
On Wed, Jun 29, 2011 at 1:39 AM, Matthew Brush mbrush@codebrainz.ca wrote:
Myself, I keep all of my Geany project files in a top-level ~/Projects directory and below that a sub-directory for each project's source tree. I also add 'configure' and 'Makefile's to my VCS ignore file as to not check them in (assuming they're auto-generated by Autotools or whatever).
From my observations, it's quite rare to see developers' personal "project files" in a project's source tree or checked into VCS. Even a Geany-specific project like geany-plugins doesn't contain a single project file in its repository (from a quick `find' for *.geany).
Then we come from very different worlds. i work fairly regularly on probably 20 source trees, not one of which uses Autotools, and regularly work across multiple PCs, so i need my project files checked in. On _one_ of them we indeed do not check in developer-specific project files, but that's because we all use different Java dev tools and the dev tools generate the project files automatically from the build (Maven) scripts. But everywhere else, it's hand-crafted GNU Make, baby :). (i.e. no project files, per se, except for what individuals commit for their own use.)
Having said that - since a geany project file contains little more than the list of open files, it's never a problem to quickly re-generate it if it isn't maintained checked in. (And the absolute paths behaviour speaks against checking them in.)
i do understand the "simplicity and elegance" of the current solution, but being someone who works on a lot of different systems, i just happen to feel that it's just fundamentally wrong vis-a-vis the larger scope of things. (That's not intended as an insult - there's also plenty fundamentally wrong with my software, and i _certainly_ don't always look at "the larger scope of things." ;)
On 29 June 2011 04:17, Stephan Beal sgbeal@googlemail.com wrote:
On Tue, Jun 28, 2011 at 7:52 PM, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
I remember such a discussion taking place some time ago. It was not so straightforward - for example, what about the files not under the project directory?
There shouldn't _be_ any files not under the project dir, at least not managed by the project management tool. IDEs are almost exclusively used for working on source-control-based projects, and every source tree is rooted in one directory.
That is one theory, but not universal. For example when multiple projects share a common part it needs to be in a separate tree because no vcs I know of allows nested working directories without a page full of caveats, and thats too mistake prone.
When storing project files in a vcs, storing sessions in them should be turned off, when I check out the project I don't care what you were last editing, or if I do thats what the vcs is for. Then you don't have the risk you ran into.
Sessions should be per user. I can't remember if it fixes this problem but there is a branch in svn with significantly improved session management, but the changes are so big that no one has had the time to review it for merge.
[...]
developers opposed even to that, can't remember why. There was also talk about storing each filename as both relative and absolute, and try to open the relative first. I thought that was implemented, but don't see it anywhere. So, for now, what you see in the title is what you get.
Storing both absolute and relative and trying both increases the risk because they have an order and Murphy says that the wrong one will always be tried first (and found :-).
Cheers Lex
On Wed, Jun 29, 2011 at 1:40 AM, Lex Trotman elextr@gmail.com wrote:
On 29 June 2011 04:17, Stephan Beal sgbeal@googlemail.com wrote:
There shouldn't _be_ any files not under the project dir, at least not managed by the project management tool. IDEs are almost exclusively used
for
working on source-control-based projects, and every source tree is rooted
in
one directory.
That is one theory, but not universal. For example when multiple projects share a common part it needs to be in a separate tree because no vcs I know of allows nested working directories without a page full of caveats, and thats too mistake prone.
That's true enough.
When storing project files in a vcs, storing sessions in them should be turned off, when I check out the project I don't care what you were last editing, or if I do thats what the vcs is for. Then you don't have the risk you ran into.
It would be a pain in the neck for me, too, having to re-open the 6 or 8 files i tend to keep open, but i will have to do that on that one particular environment. (i wasn't aware that it's an option.)
And having said that... my primary editor the past 15 years or so has been xemacs, and xemacs doesn't use project files and doesn't remember what i had opened last time. But xemacs (still) can't indent JavaScript worth a damn (the emacsen get some joy from fighting the user when it comes to indentation of JS), so i started using geany for PHP/JS stuff, and then eventually started using it for C/C++ stuff, keeping xemacs open in the background for when i need the macros. i've not a big fan of IDEs, but i simple-without-being-too-simple geany.
Storing both absolute and relative and trying both increases the risk
because they have an order and Murphy says that the wrong one will always be tried first (and found :-).
A very good point :/. Damn you, Murphy!
It would be a pain in the neck for me, too, having to re-open the 6 or 8 files i tend to keep open, but i will have to do that on that one particular environment. (i wasn't aware that it's an option.)
preferences > general > miscellaneous
Unfortunately its global, would be better if it was per project, but you can't have everything (until someone patches it).
Cheers Lex
[project files]
It would be a pain in the neck for me, too, having to re-open the 6 or 8 files i tend to keep open, but i will have to do that on that one particular environment. (i wasn't aware that it's an option.)
Not wanting to hi-jack the thread, but if your VCS happens to be git, you might want to try my Gitbrowser plug-in (https://github.com/unwind/gitbrowser) and see if that helps with this.
That means not having any Geany projects, which seems to make sense to me since:
1. The set of files that constitute the project is already stored once, by Git. 2. The rules for building the project are already stored once, in a Makefile. 3. The set of previously opened files is already tracked by Geany.
Of course, if this totally misses the mark for your use-case(s), just ignore me and carry on. :)
Regards,
/Emil
On Wed, Jun 29, 2011 at 9:24 AM, Emil Brink emil@obsession.se wrote:
Not wanting to hi-jack the thread, but if your VCS happens to be git, you might want to try my Gitbrowser plug-in (https://github.com/unwind/gitbrowser) and see if that helps with this.
If i was using git, i would certainly do so, but for me git violates the most sacred fundamentals: make it difficult to use _incorrectly_ (and every time i touch a git repo, i quickly get it into a state which only a clean checkout will recover from). For the sake of other peoples' source trees, i have forbidden myself from using git except in read-only mode. (My DVCS of choice is fossil.)
(Sorry, not to start a flame war - this is one i can't win!)
That means not having any Geany projects, which seems to make sense to me since: ...
Of course, if this totally misses the mark for your use-case(s), just
ignore me and carry on. :)
No, you're not way off the mark. i think on that particular tree i'll just disable the sessions support. Development of my other geany-using projects all takes place on machines of mine, all with the same structures, and i've been using it for 6 months or so without even noticing that it used absolute paths (but i would have bet, if asked, that it used relative paths).
But the fact that the default behaviour can lead to "utterly confusing, potentially damaging" behaviour when someone simply copies his source tree or makes a second checkout on the same machine stuff bugs the hell out of me. That behaviour is understandable (in hindsight), but very non-intuitive and unfortunate.
On 29/06/2011 15:24, Emil Brink wrote:
[project files]
It would be a pain in the neck for me, too, having to re-open the 6 or 8 files i tend to keep open, but i will have to do that on that one particular environment. (i wasn't aware that it's an option.)
Not wanting to hi-jack the thread, but if your VCS happens to be git, you might want to try my Gitbrowser plug-in (https://github.com/unwind/gitbrowser) and see if that helps with this.
That means not having any Geany projects, which seems to make sense to me since:
- The set of files that constitute the project is already stored once, by Git.
- The rules for building the project are already stored once, in a Makefile.
- The set of previously opened files is already tracked by Geany.
Of course, if this totally misses the mark for your use-case(s), just ignore me and carry on. :)
This is my cue to invite you to join the geany-plugins[1] project and bring your plugin with you :-)
On Wed, 29 Jun 2011 09:40:07 +1000 Lex Trotman elextr@gmail.com wrote:
When storing project files in a vcs, storing sessions in them should be turned off, when I check out the project I don't care what you were last editing, or if I do thats what the vcs is for. Then you don't have the risk you ran into.
Sessions should be per user. I can't remember if it fixes this problem but there is a branch in svn with significantly improved session management, but the changes are so big that no one has had the time to review it for merge.
No, SM branch doesn't fix this problem.
Regards, Eugene.
On Thu, 30 Jun 2011 08:20:02 +0400 Eugene Arshinov earshinov@gmail.com wrote:
On Wed, 29 Jun 2011 09:40:07 +1000 Lex Trotman elextr@gmail.com wrote:
Sessions should be per user. I can't remember if it fixes this problem but there is a branch in svn with significantly improved session management, but the changes are so big that no one has had the time to review it for merge.
No, SM branch doesn't fix this problem.
With sm1, you can run an instance, turn "Project based session files" off and open your project. The option will be stored in geany.conf, so you can then open several other projects with pbsf off - just be sure to turn it on and confirm at some point, unless you want it permanent. On restart, all instances will be restored with their individual pbsf values and open files. Though I'm not sure what good will that do.
On Thu, 30 Jun 2011 21:22:11 +1000 Lex Trotman elextr@gmail.com wrote:
If the project session isn't in the project file where would it be put
Under novadays Unix, in ~/.cache/geany. For Win~1, somewhere in Application Data - not sure which of them, not sure about Vista/7.
and how would it be managed so really old session data wasn't still hanging around long after the project was deleted but also so that long lived projects didn't lose their data.
Add a delete project function to the project menu, and/or ask whether to delete the session file when attempting to open a missing project.
In other words fixed based deletion is bad. Are there any well known solutions or libraries that help with it?
Not that I know off, I'm not sure how you expect such a thing to be implemented. The closest thing that comes to mind is Win~1 auto removing Foo_files/ when you delete Foo.htm, or maybe it was vice versa. Awful stuff, and not Explorer-only.
(The "40 years wisdom" which will not allow me to keep an .xml or .sql file from another team permanently open in my session was nice. Should I ask a colleagues of mine, which does have 40 years of experience? :)
On Thu, Jun 30, 2011 at 7:56 PM, Dimitar Zhekov dimitar.zhekov@gmail.comwrote:
(The "40 years wisdom" which will not allow me to keep an .xml or .sql file from another team permanently open in my session was nice. Should I ask a colleagues of mine, which does have 40 years of experience? :)
By all means - the insights of someone who's been doing this since before StarWars (that's '77, for you young 'uns) are always worth listening to. But i was certainly unclear in my reference to "40+ years" - i was referring roughly to age of the modern computing era, which (since i'm a Unixite) starts at midnight, 1 January 1970.
On Thu, 30 Jun 2011 20:10:25 +0200 Stephan Beal sgbeal@googlemail.com wrote:
On Thu, Jun 30, 2011 at 7:56 PM, Dimitar Zhekov dimitar.zhekov@gmail.comwrote:
(The "40 years wisdom" which will not allow me to keep an .xml or .sql file from another team permanently open in my session was nice. Should I ask a colleagues of mine, which does have 40 years of experience? :)
By all means - the insights of someone who's been doing this since before StarWars (that's '77, for you young 'uns) are always worth listening to.
Well he's assistand-director (not sure it's the right term), though still doing some programming, so I can't just go and ask him questions from the top of my head. But there can be no doubt that our company's practices were approved, if not heavily influenced, by him, and by our previous (now retired) director, also a former programmer. So let me tell you how we do some things relevant to this discussion:
It's normal to keep integration specs, schemas etc. from other projects open, without copying them under the project tree. In fact, making local copies of some files is explicitly forbiden - I can't say more than that, for obvious reasons.
'tis a practice for each developer to compile the modules (s)he is currently responsible for with debug info, and everything else without. And when developing new functionality, it's often initially under a #define, fully compiled and running only for the respective developers. Both things are managed with the project files, so they are under a separate backup plan, not source control.
As you can see, your views are not universal. Please don't ask me any specific questions, and there's also no need for suggestions about improving out practices.
On Fri, Jul 1, 2011 at 7:07 PM, Dimitar Zhekov dimitar.zhekov@gmail.comwrote:
...As you can see, your views are not universal.
No, they're not universal, but 99.99+% of source trees do not directly reference files outside of the source tree. i've never personally seen even one which does (and i've seen a boatload of source trees).
In any case - i've come to accept that Geany's project file is but a convenience for remembering what i was editing, and not a real "project file" (it doesn't know how to build my project - GNU make does that for me). And given that scope, it's absolute-path behaviour doesn't bother me all that much any more. But i do think the solution mentioned by Jiri and others would be "the right thing to do."
Please don't ask me any
specific questions, and there's also no need for suggestions about improving out practices.
i wouldn't think of it :).
On 2 July 2011 03:18, Stephan Beal sgbeal@googlemail.com wrote:
On Fri, Jul 1, 2011 at 7:07 PM, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
...As you can see, your views are not universal.
No, they're not universal, but 99.99+% of source trees do not directly reference files outside of the source tree. i've never personally seen even one which does (and i've seen a boatload of source trees).
Tsk tsk, monolithic software, bad practice (not that I'm criticizing mind :-)
In any case - i've come to accept that Geany's project file is but a convenience for remembering what i was editing, and not a real "project file" (it doesn't know how to build my project - GNU make does that for me).
Well it does know how to invoke the build commands (nothing stored means use the default) so if you are using something different to the "died of old age but hasn't stopped moving yet" make and its totally unportable friends autofake and autofools then the project file is where you store the commands. Thats another use case for putting project files in vcs as well as your perfectly reasonable convenience reason.
And given that scope, it's absolute-path behaviour doesn't bother me all that much any more. But i do think the solution mentioned by Jiri and others would be "the right thing to do."
Well it would do the right thing a little more often so its worth doing.
Cheers Lex
On Sat, Jul 2, 2011 at 1:35 AM, Lex Trotman elextr@gmail.com wrote:
Well it does know how to invoke the build commands (nothing stored means use the default) so if you are using something different to the "died of old age but hasn't stopped moving yet" make and its totally unportable friends autofake and autofools then the project file is where you store the commands.
i despise the "Auto, my ass!" Tools - haven't touched them in about 8 years, except as a user of projects which use them. i prefer plain old GNU make 3.81+.
And given that scope, it's absolute-path behaviour doesn't bother me all that much any more. But i do think the solution mentioned by Jiri and
others
would be "the right thing to do."
Well it would do the right thing a little more often so its worth doing.
yes, "righter thing" probably would have been a better choice of words.
i despise the "Auto, my ass!" Tools - haven't touched them in about 8 years, except as a user of projects which use them. i prefer plain old GNU make 3.81+.
Pure make is a bit back to the future,
1. doesn't handle changes to compile options unless you manually make clean and compile the lot, even if the option only applies to part
2. doesn't handle changes to dependencies other than C or C++ and then only if you remember to do make depends
(oops preaching again, time to climb off the soapbox)
Cheers Lex
PS and it gets fooled when files go back in time (rare but *really* confusing when it happens)
On Sat, Jul 2, 2011 at 2:16 AM, Lex Trotman elextr@gmail.com wrote:
Pure make is a bit back to the future,
i like make so much that i forked the O'Reilly book on the topic and update it as the need arises:
http://wanderinghorse.net/computing/make/
On Tue, Jun 28, 2011 at 19:52, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Tue, 28 Jun 2011 19:28:12 +0200 Stephan Beal sgbeal@googlemail.com wrote:
Is there an option to enable the use of relative paths in the project files?
From the look of get_session_file_string(), no.
I remember such a discussion taking place some time ago. It was not so straightforward - for example, what about the files not under the project directory? Store /var/log/foo as [../]{N times}/var/log/foo? Or, for files in a nearby directory, break them each time you copy the project and open it from the new location? (Well the last operation is dangerous currently - you'll be working on the previous files.)
It would have been nice to store anything under the project directory as relative, and everything outside as absolute, but some of the developers opposed even to that, can't remember why. There was also talk about storing each filename as both relative and absolute, and try to open the relative first. I thought that was implemented, but don't see it anywhere. So, for now, what you see in the title is what you get.
This is a part of my not-yet-reviewed patches. The only difference is that I try to open the absolute paths before the relative ones to keep the patch as compatible with the current behaviour as possible. But it's not a problem to swap the order (it looks it makes more sense when reading Stephan's problems).
Cheers,
Jiri
On Tue, Jun 28, 2011 at 9:44 PM, Jiří Techet techet@gmail.com wrote:
This is a part of my not-yet-reviewed patches. The only difference is that I try to open the absolute paths before the relative ones to keep the patch as compatible with the current behaviour as possible. But it's not a problem to swap the order (it looks it makes more sense when reading Stephan's problems).
:-D
i like the idea of first trying absolute paths, so this wouldn't break our umpteen other project files :).
To be clear: this isn't a demand - i won't hate geany if it's not added, but i will occasionally growl. i know this is your project and your time, and as an active OSS developer (but not on geany ;) i know users' feature requests aren't always the features you want to implement. But if you've got the patches laying around and it wouldn't cause too much breakage...
On Tue, 28 Jun 2011 21:44:41 +0200 Jiří Techet techet@gmail.com wrote:
On Tue, Jun 28, 2011 at 19:52, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Tue, 28 Jun 2011 19:28:12 +0200
There was also talk about storing each filename as both relative and absolute, and try to open the relative first. I thought that was implemented, but don't see it anywhere.
This is a part of my not-yet-reviewed patches.
Filenames like "../../../../../../usr/share/doc/libpng/examples.c" are something I woudn't like to see. If someone can convince the leading developers (except for the missing Nick) on a three-state per project option "Store filenames as: Always absolute / Relative if under the project directory / Relative if under the project file directory", I'll implement it, and believe it'll be shorter and more compatible. No offence.
On Tue, 28 Jun 2011 20:17:47 +0200 Stephan Beal sgbeal@googlemail.com wrote:
There shouldn't _be_ any files not under the project dir [...]
That doesn't mean you shoudn't be able to open a file outside the project directory, and AFAIK, no IDE with such limitation exists. So the project organization discussion is irrelevant.
On Wed, Jun 29, 2011 at 6:25 PM, Dimitar Zhekov dimitar.zhekov@gmail.comwrote:
Filenames like "../../../../../../usr/share/doc/libpng/examples.c" are something I woudn't like to see.
oooh, no.
On Tue, 28 Jun 2011 20:17:47 +0200 Stephan Beal sgbeal@googlemail.com wrote:
There shouldn't _be_ any files not under the project dir [...]
That doesn't mean you shoudn't be able to open a file outside the project directory, and AFAIK, no IDE with such limitation exists. So the project organization discussion is irrelevant.
But should such files, which are not part of the project, be referenced in the _project_ file? i think a case could be made for "eliding" those for session purposes.
On 30 June 2011 05:11, Stephan Beal sgbeal@googlemail.com wrote:
On Wed, Jun 29, 2011 at 6:25 PM, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Filenames like "../../../../../../usr/share/doc/libpng/examples.c" are something I woudn't like to see.
oooh, no.
On Tue, 28 Jun 2011 20:17:47 +0200 Stephan Beal sgbeal@googlemail.com wrote:
There shouldn't _be_ any files not under the project dir [...]
That doesn't mean you shoudn't be able to open a file outside the project directory, and AFAIK, no IDE with such limitation exists. So the project organization discussion is irrelevant.
But should such files, which are not part of the project, be referenced in the _project_ file? i think a case could be made for "eliding" those for session purposes.
No, my session is my session.
If I'm storing it in the project then fine but it should store my whole session, it would be *really* annoying to have something outside the tree open and then when I restarted it wasn't there :-(
Cheers Lex
Hi Dimitar,
Filenames like "../../../../../../usr/share/doc/libpng/examples.c" are something I woudn't like to see. If someone can convince the leading developers (except for the missing Nick) on a three-state per project option "Store filenames as: Always absolute / Relative if under the project directory / Relative if under the project file directory", I'll implement it, and believe it'll be shorter and more compatible. No offence.
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, so why confuse things with an option that is still always possibly wrong, KISS leave it absolute.
But if you do implement it, or instead, what about adding a "save session in project file" option into the project file so individual ones can turn it off? That would be useful for project files stored in vcs and they are the ones most likely to find themselves in some different environment since they are cloned/checked out/... to lots of places.
On Tue, 28 Jun 2011 20:17:47 +0200 Stephan Beal sgbeal@googlemail.com wrote:
There shouldn't _be_ any files not under the project dir [...]
That doesn't mean you shoudn't be able to open a file outside the project directory, and AFAIK, no IDE with such limitation exists.
Limiting to the project tree would be totally unacceptable, there are always things outside the tree that you want to open, and have re-open when you restart.
Cheers Lex
On Thu, Jun 30, 2011 at 2:29 AM, Lex Trotman elextr@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).
so why confuse things with an option that is still always
possibly wrong, KISS leave it absolute.
i agree with that, but the current behaviour is dangerous.
Limiting to the project tree would be totally unacceptable, there are always things outside the tree that you want to open, and have re-open when you restart.
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.
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.
On Thu, 30 Jun 2011 10:42:02 +0200 Stephan Beal sgbeal@googlemail.com wrote:
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.
Same here... ;-)
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.
I totally agree with you. That would be the best way.
Using relative paths would solve a second problem too. If the project file is used by linux and windows users, absolute paths are incompatible. But with paths relative to the project file's directory, window users could use the project file too.
On 30 June 2011 19:21, Joerg Desch jd.vvd@web.de wrote:
On Thu, 30 Jun 2011 10:42:02 +0200 Stephan Beal sgbeal@googlemail.com wrote:
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.
Same here... ;-)
Sigh, another young 'un..
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.
I totally agree with you. That would be the best way.
Using relative paths would solve a second problem too. If the project file is used by linux and windows users, absolute paths are incompatible. But with paths relative to the project file's directory, window users could use the project file too.
Thats true, but do you want to share which files you last edited? :-) It just emphasizes that the session data shouldn't be in the project file if its in vcs. So there should be a per project option to prevent it.
The only other path in the project file is the basepath which is user edited and is absolute or relative to the project file. Its the sessions that bit Stephan.
Cheers Lex
On Thu, 30 Jun 2011 19:51:47 +1000 Lex Trotman elextr@gmail.com wrote:
Sigh, another young 'un..
???
Thats true, but do you want to share which files you last edited? :-) It just emphasizes that the session data shouldn't be in the project file if its in vcs.
No, I don't. But geany doesn't differentiate between the project data (which should be in the VCS) and the session part.
So there should be a per project option to prevent it.
I don't understand the idea behind this option.
The only other path in the project file is the basepath which is user edited and is absolute or relative to the project file.
As Stephan mentioned in his mail, this path could be replaced by the path of the project file (he called it virtual root). Why? Just because I have more than one working directory. I have a development release and one or more branches / customer releases checked out. If the project file would use the virtual root, I would have only one project file to load.
With the current "~/Project" way, I have to (a) copy the project file and end with multiple project files, or (b) have to fix the project file.
Its the sessions that bit Stephan.
I don't think so. But I think he will tell us... ;-)
On Thu, Jun 30, 2011 at 12:17 PM, Joerg Desch jd.vvd@web.de wrote:
On Thu, 30 Jun 2011 19:51:47 +1000 Lex Trotman elextr@gmail.com wrote:
Its the sessions that bit Stephan.
I don't think so. But I think he will tell us... ;-)
Lex was right -it was a side-effect of the session handling which bit me. But that only brought my attention to the fact that geany uses absolute paths for everything, so the "problem" is bigger than just session handling.
However, even if the session handling is changed to be per-project-file-instance (per USER would still have hosed me here), i feel very strongly that having absolute paths in the project file is fundamentally wrong.
From your previous post...
And i believe that such a use-case lies in the realm of gnome-text-editor instead of an IDE. IDEs are (traditionally) designed to manage specific source-based projects, not OS-wide collections of arbitrary trees.
Thats a very narrow view of what an IDE is/can be used for. The characteristics of an IDE encompass many more features than how they manage trees, and those features are not just the prerogative of "professional" programmers, it isn't reasonable to use Geany as open source software and say that its features shouldn't be available to other open source projects, however they are organised, and even if they don't have .geany files in their repositories. And copying a .geany into the working tree is going to invite the attention of the vcs. And no you can't add *.geany to the .(your vcs here)ignore file, its under control too.
On 30 June 2011 20:25, Stephan Beal sgbeal@googlemail.com wrote:
On Thu, Jun 30, 2011 at 12:17 PM, Joerg Desch jd.vvd@web.de wrote:
On Thu, 30 Jun 2011 19:51:47 +1000 Lex Trotman elextr@gmail.com wrote:
Its the sessions that bit Stephan.
I don't think so. But I think he will tell us... ;-)
Lex was right -it was a side-effect of the session handling which bit me. But that only brought my attention to the fact that geany uses absolute paths for everything, so the "problem" is bigger than just session handling.
Other than sessions, the only paths in the project files are:
1. basepath which can be relative to the project file or absolute, and 2. build working directories which can be relative to the source file or relative to the project or absolute.
All these are under user control, or have I missed some other problem?
However, even if the session handling is changed to be per-project-file-instance (per USER would still have hosed me here), i feel very strongly that having absolute paths in the project file is fundamentally wrong.
Well, given that I am saying that really we shouldn't have *any* session paths in the project file I guess we sort of agree here. Just not about how to fix it.
Cheers Lex
On Thu, Jun 30, 2011 at 12:54 PM, Lex Trotman elextr@gmail.com wrote:
From your previous post...
And i believe that such a use-case lies in the realm of gnome-text-editor
instead of an IDE. IDEs are (traditionally) designed to manage specific source-based projects, not OS-wide collections of arbitrary trees.
Thats a very narrow view of what an IDE is/can be used for. The characteristics of an IDE encompass many more features than how they manage trees, and those features are not just the prerogative of "professional" programmers, it isn't reasonable to use Geany as open source software and say that its features shouldn't be available to other open source projects, however they are organised, and even if
If it's not geared towards development then it shouldn't be called an IDE (Integrated Development Environment), but a Project Management tool (which is going a bit far, i think, seeing that a project is simply a list of open files) or "Glorified Editor".
Geany is filled to the brim with software-development-specific features - it is unequivocally an IDE, and IDEs are for managing source projects. Source projects are, almost without exception, rooted under a single directory (perhaps consisting of several modules checked out from different sources, but that's besides the point). i say "almost without exception" because if i say "without exception" someone will prove me wrong. But in my not inconsiderable experience the term "always" is more accurate.
they don't have .geany files in their repositories. And copying a .geany into the working tree is going to invite the attention of the vcs. And no you can't add *.geany to the .(your vcs here)ignore file, its under control too.
One is never forced to add a file to vcs just because svn reports a '?' next to it in 'svn status'. Yes, it's slightly annoying to have '?' show up in the status, but it's nothing new (object files show up there, too).
On 30 June 2011 20:25, Stephan Beal sgbeal@googlemail.com wrote:
On Thu, Jun 30, 2011 at 12:17 PM, Joerg Desch jd.vvd@web.de wrote: However, even if the session handling is changed to be per-project-file-instance (per USER would still have hosed me here), i
feel
very strongly that having absolute paths in the project file is fundamentally wrong.
Well, given that I am saying that really we shouldn't have *any* session paths in the project file I guess we sort of agree here. Just not about how to fix it.
Fair enough. i admit that i am a bit of a hard-liner/hard-ass on this point, but that's because i think Geany is trying to fill the "please everyone" role, and at the same time breaking this important feature for the core (99%+) market - developers who work under "rooted" software trees.
As Stephan mentioned in his mail, this path could be replaced by the path of the project file (he called it virtual root). Why? Just because I have more than one working directory. I have a development release and one or more branches / customer releases checked out. If the project file would use the virtual root, I would have only one project file to load.
I'm not sure I totally understand you, if the project file is in the vcs and the base path is relative to the project file why do you have to copy it?
Cheers Lex
On Thu, 30 Jun 2011 20:36:31 +1000 Lex Trotman elextr@gmail.com wrote:
As Stephan mentioned in his mail, this path could be replaced by the path of the project file (he called it virtual root). Why? Just because I have more than one working directory. I have a development release and one or more branches / customer releases checked out. If the project file would use the virtual root, I would have only one project file to load.
I'm not sure I totally understand you, if the project file is in the vcs and the base path is relative to the project file why do you have to copy it?
OK. I thought, that the base path must be absolute. But to get the expected behavior, I must use . as base path, which seams to work here on linux. The session informations stored in section [files] are still using an absolute path. Is this the point where a project option you've mentioned could help?
OK. I thought, that the base path must be absolute. But to get the expected behavior, I must use . as base path, which seams to work here on
You can use . or a single name (which has to be in the same directory as the project file) and still remain win-ix compatible, after that path separators stuff it up.
linux. The session informations stored in section [files] are still using an absolute path. Is this the point where a project option you've mentioned could help?
The [files] are the session files that I'm suggesting shouldn't really be in the project files.
Cheers Lex
linux. The session informations stored in section [files] are still using an absolute path. Is this the point where a project option you've mentioned could help?
The [files] are the session files that I'm suggesting shouldn't really be in the project files.
A question for Eugene or Dimitar the session specialists (or anyone with an answer).
If the project session isn't in the project file where would it be put, and how would it be managed so really old session data wasn't still hanging around long after the project was deleted but also so that long lived projects didn't lose their data. In other words fixed time based deletion is bad.
Are there any well known solutions or libraries that help with it?
Cheers Lex
On Thu, Jun 30, 2011 at 12:54 PM, Joerg Desch jd.vvd@web.de wrote:
OK. I thought, that the base path must be absolute. But to get the expected behavior, I must use . as base path, which seams to work here on linux. The session informations stored in section [files] are still using an absolute path. Is this the point where a project option you've mentioned could help?
My thinking was:
... [project] name=.... base_path=/kunden/....
^^^^^ base_path goes awy away completely. It's not needed - base_dir is computed from the path holding the project file. For this example, let's assume my project file is in /kunden/. (that's German for "customers").
[files] FILE_NAME_0=26926;PHP;0;16;1;1;0;/kunden/abc/def/foo.bar;0 FILE_NAME_1=0;PHP;0;16;1;1;0;/kunden/.../isr_invsr_single_edit.php;0
Would become:
FILE_NAME_0=26926;PHP;0;16;1;1;0;abc/def/foo.bar;0 FILE_NAME_1=0;PHP;0;16;1;1;0;.../isr_invsr_single_edit.php;0
etc. etc.
If, despite the wisdom of 40+ years of collective software development conventions, i place files outside of my project root, they are still handled:
FILE_NAME_0=...;TEXT;0;16;1;1;0;/etc/hosts;0
On 30 June 2011 21:22, Stephan Beal sgbeal@googlemail.com wrote:
On Thu, Jun 30, 2011 at 12:54 PM, Joerg Desch jd.vvd@web.de wrote:
OK. I thought, that the base path must be absolute. But to get the expected behavior, I must use . as base path, which seams to work here on linux. The session informations stored in section [files] are still using an absolute path. Is this the point where a project option you've mentioned could help?
My thinking was: ... [project] name=.... base_path=/kunden/.... ^^^^^ base_path goes awy away completely. It's not needed - base_dir is
As said previously, base path is needed when the project file cannot be in the working tree.
Your suggestion only addresses one use-case when the project file *is* in the tree, it doesn't address the other one when the programmer doesn't control the project and can't put the project file in the tree.
Cheers Lex
PS My first programming was 1973 with punched cards, still 10 years more :-D (oooh I feel old...)
On Thu, Jun 30, 2011 at 1:35 PM, Lex Trotman elextr@gmail.com wrote:
Your suggestion only addresses one use-case when the project file *is* in the tree, it doesn't address the other one when the programmer doesn't control the project and can't put the project file in the tree.
You haven't yet shown us a use case which actually does that. There is almost never, with the rare exception of read-only source trees, a case where the project file _cannot_ be put in the root of the source tree. If the source tree is read-only then you can't edit the sources and geany does the user absolutely no good whatsoever (except as a glorified text browser).
It would be interesting to know if the major IDEs support absolute paths. (i have no idea, as xemacs doesn't use project files.)
PS My first programming was 1973 with punched cards, still 10 years more :-D (oooh I feel old...)
LOL! i'm not envious - i'm glad i didn't have to "write the tools with which to write the tools."
[...]
It would be interesting to know if the major IDEs support absolute paths. (i have no idea, as xemacs doesn't use project files.)
Well actually emacs saves session files as absolute. Even if they are saved in the source tree. M-x desktop-save and then look in .emacs.desktop.
Cheers Lex
On Thu, 30 Jun 2011 21:35:05 +1000 Lex Trotman elextr@gmail.com wrote:
As said previously, base path is needed when the project file cannot be in the working tree.
The solution could be to define base_path if the project file is outside. If base_path is empty, its in the working tree.
PS My first programming was 1973 with punched cards, still 10 years more :-D (oooh I feel old...)
Nice. My first computer was as self built Apple-II clone. Just a PCB and a bag of ICs. I don't remember the year...
On 30 June 2011 18:42, Stephan Beal sgbeal@googlemail.com wrote:
On Thu, Jun 30, 2011 at 2:29 AM, Lex Trotman elextr@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
On Thu, Jun 30, 2011 at 11:40 AM, Lex Trotman elextr@gmail.com wrote:
I'm sure you had a very embarrassing interview with someone about why you broke the production server and are very annoyed with yourself,
i didn't actually - the marketing people who complained got the generic technical explanation that a software bug caused it.
especially as the full file path shows in the title bar ('aint I a
Nobody who works with a document-editing tool reads the titlebar on a regular basis.
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.
It does if one does NOT use .. in the path names: use names in the form a/b/c or /a/b/c. i have implemented this in my own software and know it to be reliable. Storing relative paths ".." in them is just downright dangerous.
[...]
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.
But such forests are (A) managed under a single common root or (B) they are are not managed via a single project file (i.e. not by IDEs).
The problem here is simply the session records rather than anything else.
Right.
- session files which are the concern of the individual programmer and
- project data which does go with the project tree.
Amen.
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.
And i believe that such a use-case lies in the realm of gnome-text-editor instead of an IDE. IDEs are (traditionally) designed to manage specific source-based projects, not OS-wide collections of arbitrary trees.
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.
If i was hacking the /usr/src/linux i would drop (or symlink) my .geany file into that directory. Problem solved. With the current behaviour, my project file will be invalid the next time i upgrade and get /usr/src/linux-X.Y.Z+1.
i'm not convinced that having the project file outside the repo provides any benefit or any safety against path-related errors. Not only that, but it challenges common conventions (unsuccessfully, it turns out).
And when the project file is outside the tree then absolute makes sense.
Then store those as /a/b/c instead of a/b/c. Problem solved.
On Thu, Jun 30, 2011 at 11:51 AM, Lex Trotman elextr@gmail.com wrote:
On 30 June 2011 19:21, Joerg Desch jd.vvd@web.de wrote:
On Thu, 30 Jun 2011 10:42:02 +0200 Stephan Beal sgbeal@googlemail.com wrote:
i've been programming professionally for going on 20 years now, and i
...
Same here... ;-)
Sigh, another young 'un..
But hobby-wise going on 30 years - since 25 December, 1983 :). My first line of code was something like:
CALL CLEAR
On 06/30/11 03:00, Stephan Beal wrote:
On Thu, Jun 30, 2011 at 11:40 AM, Lex Trotman <elextr@gmail.com mailto:elextr@gmail.com> wrote:
I'm sure you had a very embarrassing interview with someone about why you broke the production server and are very annoyed with yourself,i didn't actually - the marketing people who complained got the generic technical explanation that a software bug caused it.
The good old PEBKAC bug :)
especially as the full file path shows in the title bar ('aint I aNobody who works with a document-editing tool reads the titlebar on a regular basis.
Nobody?
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.And i believe that such a use-case lies in the realm of gnome-text-editor instead of an IDE. IDEs are (traditionally) designed to manage specific source-based projects, not OS-wide collections of arbitrary trees.
The way I store the project files has nothing to do with OS-wide collections of arbitrary trees or realms of wrongly named editors, it has to do with not storing my project/session data in a public source tree where other coders have no interest in it. Why does the guy on the other side of the world who uses VIM or Emacs care what build commands I use in Geany? And what would the Debian packager making a package of the source tree care what indentation settings one of the many developers uses? Would the project's core developers want a changeset which includes noise from changing project files? What about Joe Random User scanning the source tree, would he get confused by all the geany, anjuta, vim, emacs, eclipse, etc files littering the source tree root?
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.If i was hacking the /usr/src/linux i would drop (or symlink) my .geany file into that directory. Problem solved. With the current behaviour, my project file will be invalid the next time i upgrade and get /usr/src/linux-X.Y.Z+1.
Or you could just have your project file in /usr/src and point to the project base directory of /usr/src/linux where the current tree will/should always be symlinked to. I can't even imagine what the kernel source tree would look like littered with the probably hundreds of different editor/IDE project files that it's thousands of developers use between them.
i'm not convinced that having the project file outside the repo provides any benefit or any safety against path-related errors. Not only that, but it challenges common conventions (unsuccessfully, it turns out).
The benefit is that you don't have it in VCS, so when you checkout the code somewhere else, you don't have John Coder's IDE-specific project file in the tree pointing to files stored god knows where :)
I can't think of a single project's source tree I've checked out where the developers store their personal editor/IDE preferences in the project's source tree, at least not that I've noticed. Still, I don't think it would qualify as "common convention", except maybe with VisualStudio projects/solutions.
But hobby-wise going on 30 years - since 25 December, 1983 :). My first line of code was something like:
I was 1 year old in 1983, but I was already coding in QBasic :)
Cheers, Matthew Brush
On Thu, Jun 30, 2011 at 1:57 PM, Matthew Brush mbrush@codebrainz.ca wrote:
Nobody who works with a document-editing tool reads the titlebar on a regular basis.
Nobody?
Not on a regular basis -i know what document i'm supposed to be editing and i don't double-check. i look at the tab name, but that's just the basename.
Or you could just have your project file in /usr/src and point to the
project base directory of /usr/src/linux where the current tree will/should always be symlinked to.
Symlinks typically get resolved to full paths by applications, making a symlink useless for this case. (i have not tried whether geany resolves them, but assume that it must for portability reasons).
any benefit or any safety against path-related errors. Not only that,
but it challenges common conventions (unsuccessfully, it turns out).
The benefit is that you don't have it in VCS, so when you checkout the code somewhere else, you don't have John Coder's IDE-specific project file in the tree pointing to files stored god knows where :)
i don't agree that this perceived benefit outweighs the problems caused by the inconsistency vis-a-vis common conventions. Show us _one_ non-geany IDE which uses absolute paths in the project file names. In the past hour i've been digging around my system looking for project files for a couple apps on my system (not IDEs), and not one of them uses absolute paths.
I can't think of a single project's source tree I've checked out where the developers store their personal editor/IDE preferences in the project's source tree, at least not that I've noticed.
Correct - but many of them have a single project file which the developers can use (e.g. maven build files which can be used developer-side to create IDE-specific project files). Scons and qmake also come to mind. And _those_ most certainly _do not_ use absolute paths because that makes them useless for cross-machine (or even 2x on one machine) purposes.
Still, I don't think it would qualify as "common convention", except maybe with VisualStudio projects/solutions.
Like it or not, VisualStudio _is_ the common convention. i don't use it (haven't used a Windows desktop since last millennium), but many, many people do. Others which come to mind: Qmake, Maven, and Jakarta Ant (all used as the basis for several IDE-dependent project-file generators and none of which requires absolute paths).
On 30 June 2011 22:10, Stephan Beal sgbeal@googlemail.com wrote:
On Thu, Jun 30, 2011 at 1:57 PM, Matthew Brush mbrush@codebrainz.ca wrote:
Nobody who works with a document-editing tool reads the titlebar on a regular basis.
Nobody?
Not on a regular basis -i know what document i'm supposed to be editing and i don't double-check. i look at the tab name, but that's just the basename.
Yeah guilty here too ...
Or you could just have your project file in /usr/src and point to the project base directory of /usr/src/linux where the current tree will/should always be symlinked to.
Symlinks typically get resolved to full paths by applications, making a symlink useless for this case. (i have not tried whether geany resolves them, but assume that it must for portability reasons).
I'm not sure what you mean by this, when should it "resolve" them?
any benefit or any safety against path-related errors. Not only that, but it challenges common conventions (unsuccessfully, it turns out).
The benefit is that you don't have it in VCS, so when you checkout the code somewhere else, you don't have John Coder's IDE-specific project file in the tree pointing to files stored god knows where :)
i don't agree that this perceived benefit outweighs the problems caused by the inconsistency vis-a-vis common conventions. Show us _one_ non-geany IDE which uses absolute paths in the project file names. In the past hour i've been digging around my system looking for project files for a couple apps on my system (not IDEs), and not one of them uses absolute paths.
Ummmm, guys, lets be specific, we are only talking about the session files here, all other paths *can* be relative.
And I agree with Matthew, that session data doesn't belong in version control. And unless its an in-house project with a controlled tool set neither does the project file for all the reasons Matthew enumerates. Note that even Geany doesn't offer a .geany project file in svn.
[...]
Correct - but many of them have a single project file which the developers can use (e.g. maven build files which can be used developer-side to create IDE-specific project files). Scons and qmake also come to mind. And _those_ most certainly _do not_ use absolute paths because that makes them useless for cross-machine (or even 2x on one machine) purposes.
Still, I don't think it would qualify as "common convention", except maybe with VisualStudio projects/solutions.
Like it or not, VisualStudio _is_ the common convention. i don't use it (haven't used a Windows desktop since last millennium), but many, many people do. Others which come to mind: Qmake, Maven, and Jakarta Ant (all used as the basis for several IDE-dependent project-file generators and none of which requires absolute paths).
You are talking about build system control files (make, qmake, ant, maven etc) which of course live in the tree and use relative paths, but they have nothing to do with IDE project files (*.geany, eclipse .project etc) or session files.
Cheers Lex
-- ----- stephan beal http://wanderinghorse.net/home/stephan/
Geany mailing list Geany@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Thu, Jun 30, 2011 at 2:54 PM, Lex Trotman elextr@gmail.com wrote:
I'm not sure what you mean by this, when should it "resolve" them?
cd ~/tmp ln -s /etc/hosts foo
~/tmp/foo "resolves to" /etc/hosts
i'm looking for the relevant unix functions but i'm not finding them.
Ummmm, guys, lets be specific, we are only talking about the session files here, all other paths *can* be relative.
But as long as the session data is in the project file, they're the same thing.
And I agree with Matthew, that session data doesn't belong in version control.
Amen.
And unless its an in-house project with a controlled tool set neither does the project file for all the reasons Matthew enumerates. Note that even Geany doesn't offer a .geany project file in svn.
Geany's project files don't contain things like specific build flags and such, so i agree -they don't necessarily belong in svn (but it is convenient for me to do so because i frequently edit the same trees on 2-3 machines).
You are talking about build system control files (make, qmake, ant, maven etc) which of course live in the tree and use relative paths, but they have nothing to do with IDE project files (*.geany, eclipse .project etc) or session files.
You're right - i've been drawn into two different arguments without realizing it.
Seeing as geany's project file is basically just the session data and the root path of the project, i'm going to stop harping on this point and just stop putting my .geany files in source control. So i'll shut up now :).
Well actually emacs saves session files as absolute. Even if they are saved in the source tree. M-x desktop-save and then look in .emacs.desktop.
i don't use sessions in emacs, so i didn't know that.
Happy Hacking!
On 06/28/11 10:28, Stephan Beal wrote:
Is there an option to enable the use of relative paths in the project files?
I haven't checked it out yet myself, but I wonder if Jiri's GProject[1] plugin handles this a little better?
[1] http://gitorious.org/~techy/geany/gproject-geany
Cheers, Matthew Brush
On Thu, Jun 30, 2011 at 19:07, Matthew Brush mbrush@codebrainz.ca wrote:
On 06/28/11 10:28, Stephan Beal wrote:
Is there an option to enable the use of relative paths in the project files?
I haven't checked it out yet myself, but I wonder if Jiri's GProject[1] plugin handles this a little better?
There are tow different kinds of project files:
* session files - i.e. the list of open files that are stored in the project file (those discussed in this thread). GProject just extends Geany's project handling so these behave the same way as in Geany.
* project files - i.e. all files belonging to the project. These are defined by the base path and a pattern list. Any file under the base directory (and all the subdirectories) matching the pattern belongs to the project and is displayed in the tree in the sidebar.
The patch I was mentioning previously in the thread does indeed store relative paths to files outside the project directory like "../../../foo/bar/baz.c". Actually the patch was created to solve a different problem than Stephan had - it was created to solve the problem that you lose your list of open files when you move your project directory (which is pretty annoying when you regularly copy your project to a different path). I wasn't thinking much about files outside the project directory (I don't use these). With this in mind, the best solution I think is:
* to store relative paths in addition to absolute paths only for files below the directory where the project file is stored * to store only the absolute path for files outside this directory (so there's no ../ prefix in the path)
When loading the project, relative paths would be read first (when they exist). I believe this is a quite safe approach (of course you can fool it if you wish but you can fool any other method too). The modification of my patch would be pretty trivial to work this way.
Cheers, Jiri
Am 30.06.2011 23:28, schrieb Jiří Techet:
- to store relative paths in addition to absolute paths only for files
below the directory where the project file is stored
- to store only the absolute path for files outside this directory (so
there's no ../ prefix in the path)
When loading the project, relative paths would be read first (when they exist). I believe this is a quite safe approach (of course you can fool it if you wish but you can fool any other method too). The modification of my patch would be pretty trivial to work this way.
That sounds good to me as well!
BTW, my use case of project file is to store them in my "workspace", i.e. my folder where I clone/checkout all programs into. So the project file isn't in the project directory, but one level up (the project file and the project directory are in the same folder).
Best regards.