Hi all,
During the development of the build-system branch there has been a suggestion that there needs to be an upgrade of the setting of the directory in which build menu commands are run.
Currently the operation is:
Filetype commands are intended to be run on the currently open file, so they always run in the source file directory. This allows them to be used for simple single file work without configuration, and allows movement around more complex source trees, again without configuration.
Non-filetype commands are a bit more complicated. Since this group is intended to run commands independent of the source file, in theory it could be any directory, But there are a couple of likely candidates: - for make type builders to build the entire package the top of the tree is the right place, that is a fixed directory (at least for each package it is) - for make type bulders that build lower levels than the whole package, then somewhere below the top of the tree is right, that isn't a fixed directory (an example of where you use this is make doc in geany's doc subdirectory)
The current behaviour of Geany is to provide an approximation of both, at least if you are using a project. A fixed directory for all commands for this package is provided by the base_dir of the project, otherwise the directory of the current file is used as the most likely place to run commands within the tree. (Note although it is called the project base directory, I am not aware of any reason why it can't be set to any arbitrary directory)
When running without a project there is no base_dir available, so Geany runs commands in the directory of the current file or not at all. This could be improved by having a preference for a common directory (a base_dir for non-project use) and by having per-command directories.
Suggested addition
Now that build menu items are fully configurable, Thomas has suggested that there be a directory configured per command and I agree with him for the non-filetype and execute commands, filetype commands should always run in the directory of the file.
To select known directories such as the base_dir or the directory of the current file, substitutions such as %p for project could be used (like %e and %f in the commands).
If one of the substitutions is the directory of the project file, then all paths could effectively be made relative to the project file and if it is in the source tree, so allow it to be moved around with the source tree without re-configuration, and even checked into version control and checked out in a working directory somewhere else. This would be really useful when a project configured special commands as new users wouldn't have to re-configure them.
Please let me know agree/disagree.
There is a new commit in the build-system branch that makes the error regular expressions work, I think. I find it very hard to test since you need a compiler or other command that outputs errors in a format that Geany's built-in parsing doesn't recognise, and it recognises a lot. If you have such an animal please try it out.
Cheers Lex
Lex Trotman schrieb:
Hi all,
During the development of the build-system branch there has been a suggestion that there needs to be an upgrade of the setting of the directory in which build menu commands are run.
Currently the operation is:
Filetype commands are intended to be run on the currently open file, so they always run in the source file directory. This allows them to be used for simple single file work without configuration, and allows movement around more complex source trees, again without configuration.
Non-filetype commands are a bit more complicated. Since this group is intended to run commands independent of the source file, in theory it could be any directory, But there are a couple of likely candidates:
- for make type builders to build the entire package the top of the
tree is the right place, that is a fixed directory (at least for each package it is)
- for make type bulders that build lower levels than the whole
package, then somewhere below the top of the tree is right, that isn't a fixed directory (an example of where you use this is make doc in geany's doc subdirectory)
The current behaviour of Geany is to provide an approximation of both, at least if you are using a project. A fixed directory for all commands for this package is provided by the base_dir of the project, otherwise the directory of the current file is used as the most likely place to run commands within the tree. (Note although it is called the project base directory, I am not aware of any reason why it can't be set to any arbitrary directory)
When running without a project there is no base_dir available, so Geany runs commands in the directory of the current file or not at all. This could be improved by having a preference for a common directory (a base_dir for non-project use) and by having per-command directories.
Suggested addition
Now that build menu items are fully configurable, Thomas has suggested that there be a directory configured per command and I agree with him for the non-filetype and execute commands, filetype commands should always run in the directory of the file.
To select known directories such as the base_dir or the directory of the current file, substitutions such as %p for project could be used (like %e and %f in the commands).
If one of the substitutions is the directory of the project file, then all paths could effectively be made relative to the project file and if it is in the source tree, so allow it to be moved around with the source tree without re-configuration, and even checked into version control and checked out in a working directory somewhere else. This would be really useful when a project configured special commands as new users wouldn't have to re-configure them.
Please let me know agree/disagree.
There is a new commit in the build-system branch that makes the error regular expressions work, I think. I find it very hard to test since you need a compiler or other command that outputs errors in a format that Geany's built-in parsing doesn't recognise, and it recognises a lot. If you have such an animal please try it out.
Cheers Lex
Ah, I see you begin to understand where I was coming from :)
I think %d (for the directory of the current file) and %p (for the project's base dir) would already be sufficient for most stuff.
Here's the patch (sync'd to your latest changes) that allows for easier plugging in the working dir GtkEntry. It doesn't implement it yet, just makes later adding easier (I'm in favor of atomic comm its where possible, so the actual addition would be a seperate patch).
Best regards.
Ah, I see you begin to understand where I was coming from :)
I think %d (for the directory of the current file) and %p (for the project's base dir) would already be sufficient for most stuff.
Agree, lets start there.
Here's the patch (sync'd to your latest changes) that allows for easier plugging in the working dir GtkEntry. It doesn't implement it yet, just makes later adding easier (I'm in favor of atomic comm its where possible, so the actual addition would be a seperate patch).
Thanks, committed, I moved your little convenience routines to the top, out of the section of the file dealing with command execution
in function read_row I put the strlen calls back in, this is needed to check if all the entries are still blank then we don't want to make the command exist. the stcmp and strlen tests need to be in loops to match the rest of your changes, the test of dir will of course go away when you add the new entry
Re atomic commits, in theory I agree, but for me practicality intrudes. My upload is much slower than download so it is more practical to do one big commit at the end of the day rather than interrupting my day waiting for several little ones.
Cheers Lex
Best regards.
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
Thanks, committed, I moved your little convenience routines to the top, out of the section of the file dealing with command execution
That's fine!
in function read_row I put the strlen calls back in, this is needed to check if all the entries are still blank then we don't want to make the command exist. the stcmp and strlen tests need to be in loops to match the rest of your changes, the test of dir will of course go away when you add the new entry
Re atomic commits, in theory I agree, but for me practicality intrudes. My upload is much slower than download so it is more practical to do one big commit at the end of the day rather than interrupting my day waiting for several little ones.
Uploading a few text files should take long no matter of the connection. Maybe the Geany SVN is slow sometimes (geany-plugins definitely is)? Also, I'd commit myself if I could, haha :D
I started working on the working dir. I have already implemeted the entry boxes, saving and loading it. I'm just mostly finished "%d".
I'm thinking the basedir checkbox could be removed at the very end?
Best regards.
On Wed, 15 Jul 2009 22:02:48 +0200 Thomas Martitz thomas.martitz@student.HTW-Berlin.de wrote:
Lex Trotman schrieb:
Thanks, committed, I moved your little convenience routines to the top, out of the section of the file dealing with command execution
That's fine!
in function read_row I put the strlen calls back in, this is needed to check if all the entries are still blank then we don't want to make the command exist. the stcmp and strlen tests need to be in loops to match the rest of your changes, the test of dir will of course go away when you add the new entry
Re atomic commits, in theory I agree, but for me practicality intrudes. My upload is much slower than download so it is more practical to do one big commit at the end of the day rather than interrupting my day waiting for several little ones.
Uploading a few text files should take long no matter of the connection. Maybe the Geany SVN is slow sometimes (geany-plugins definitely is)? Also, I'd commit myself if I could, haha :D
Its an common issue on sourceforge. When thinking about, how many projects are using their infrastructure its understandable why ;) I'm using a local git svn repository and so I can synch asynchronous. But this is another topic ....
Cheers, Frank
Thomas Martitz schrieb:
I started working on the working dir. I have already implemeted the entry boxes, saving and loading it. I'm just mostly finished "%d".
I'm thinking the basedir checkbox could be removed at the very end?
Best regards.
Alright, I've been coding the past few hours and this is what I got so far.
It works pretty much as I expected. You fill out working dir, then it would 'cd' into that before executing the command. I'm not aware of big any issue, except that there are no default values yet (I'm not sure if they are needed if the default values would be just %d anyway).
%d and %p also work. I really think the basedir checkbox (and responsible code) could be removed.
Best regards.
Thomas,
Patch committed.
2009/7/16 Thomas Martitz thomas.martitz@student.htw-berlin.de
Thomas Martitz schrieb:
I started working on the working dir. I have already implemeted the entry boxes, saving and loading it. I'm just mostly finished "%d".
I'm thinking the basedir checkbox could be removed at the very end?
Best regards.
Alright, I've been coding the past few hours and this is what I got so far.
It works pretty much as I expected. You fill out working dir, then it would 'cd' into that before executing the command. I'm not aware of big any issue, except that there are no default values yet (I'm not sure if they are needed if the default values would be just %d anyway).
Yeah, just leave them NULL. One area that needs work is reading old config file [build-settings] to put %p/%d in the directory. Done & improved as well :-)
%d and %p also work. I really think the basedir checkbox (and responsible code) could be removed.
Agreed, done
Couple of notes,
build_replace_placeholder requires that a document is open, but non-filetype commands don't require a document, obviously you can't substitute %d in that case & should give error like %p if no project, but you can still substitute %p. Use case for make without document, grab a new working directory from VC with included project.geany file, open project and do first build, no documents need be open. I ran out of time to do it by the time I found it.
Changed the dialog comment to just list the substitutes and refer to manual, it was too long & the dialog is now pretty big (IMHO the comment I had was always too long, its not just the latest additions)
Dialog fixed regular expression field span & use symbols for column counts.
Fixed stcmp to original code, the strlen is required because a NULL must compare equal to an empty string, that was really the point of stcmp. Otherwise extraneous entries are written to config files hiding things that should still be visible (took hours to find out why ;-).
In general it seems to be working :-D
Cheers Lex
Best regards.
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Lex Trotman schrieb:
Thomas,
Patch committed.
Thanks :)
2009/7/16 Thomas Martitz <thomas.martitz@student.htw-berlin.de mailto:thomas.martitz@student.htw-berlin.de>
Thomas Martitz schrieb: I started working on the working dir. I have already implemeted the entry boxes, saving and loading it. I'm just mostly finished "%d". I'm thinking the basedir checkbox could be removed at the very end? Best regards. Alright, I've been coding the past few hours and this is what I got so far. It works pretty much as I expected. You fill out working dir, then it would 'cd' into that before executing the command. I'm not aware of big any issue, except that there are no default values yet (I'm not sure if they are needed if the default values would be just %d anyway).
Yeah, just leave them NULL. One area that needs work is reading old config file [build-settings] to put %p/%d in the directory. Done & improved as well :-)
Alright, cool!
%d and %p also work. I really think the basedir checkbox (and responsible code) could be removed.
Agreed, done
Couple of notes,
build_replace_placeholder requires that a document is open, but non-filetype commands don't require a document, obviously you can't substitute %d in that case & should give error like %p if no project, but you can still substitute %p.
Ahh yea, I forgot about the stupid user that try to compile or execute *no file* :D But yea, you're right it should be fixed.
Changed the dialog comment to just list the substitutes and refer to manual, it was too long & the dialog is now pretty big (IMHO the comment I had was always too long, its not just the latest additions)
Dialog fixed regular expression field span & use symbols for column counts.
Fixed stcmp to original code, the strlen is required because a NULL must compare equal to an empty string, that was really the point of stcmp. Otherwise extraneous entries are written to config files hiding things that should still be visible (took hours to find out why ;-).
Ah yes, did I change it? I didn't actually mean to (i.e. I had it changed locally but wanted to revert that part before putting a patch up), sorry for that.
Best regards.
I found a problem/leak. I was using variable while debugging and forgot to remove it, it's not freed as well (see patch). :(
Best regards.
On Wed, 15 Jul 2009 22:02:48 +0200, Thomas wrote:
Uploading a few text files should take long no matter of the connection. Maybe the Geany SVN is slow sometimes (geany-plugins definitely is)? Also, I'd commit myself if I could, haha :D
Both SVN servers are equally slow as both are hosted at Sourceforge.net. Sometimes they are not as slow as usual, mostly not :(.
Regards, Enrico