On Fri, 3 Oct 2008 17:32:26 +1000 "Lex Trotman" elextr@gmail.com wrote:
- Compile, build and run are filetype specific and get their command
from the filetype config (question what is runcmd2 config for?)
It's only used for the LaTeX filetype so you can view a .dvi and view .pdf files.
- Make all. Make Object and Make custom are not file specific but add
different targets to the make command stored in preferences or default a. since Make Object needs to find a target name it uses the current file name + '.o' (seems to be hard coded irrespective of platform) b. 'all' is hard coded
I know some windows compilers use .obj, but as you said it's currently hard coded. Also perhaps 'make' would be a more flexible default than 'make all'.
c. custom reads from a dialog
- %e and %f are substituted in the build command
- directory to run the resulting command is project file directory or
source file directory depending on preference 5. output is parsed for errors based on filetype, not sure how it works if there are mixed languages or compiler types, which filetype does it use?
Yes, I recently added support for a custom error regex per filetype. But you're right that for projects there should be a way to tell Geany what filetype is in use.
It defaults to a GNU-style error, "filename:line: message".
- output is parsed for "Entering directory" messages to find the
source file with errors (since the error message doesn't have the full path and the same filename could occur be in several directories)
Yes, I guess ideally this would be a configurable regex also (unlikely to be standard, even for Make implementations).
The problems with this system are:
- potential confusion from two ways of building without it being
obvious that this is the case 2. make command taken from the preferences means the user has to change the commands when moving from software with on one system to software with another 3. there are a couple of hard coded pieces
The solution to 2. and 3. is to store everything make related with the source tree, not with the preferences, and the suggested place to store it is the project file.
Yes.
...
I suggest the following changes for the three 'make' commands:
- to keep the menu size the same and so not have to fiddle with the
latex stuff that replaces the build menu, add a fourth 'make' command to replace the compile command, longer term the latex stuff should be in its own menu
We want to 'standardize' the latex commands and only have one build menu. The 'Make Object' command is like a compile command, not sure how a fourth make command would change this.
Variable numbers of commands and submenus I'd postpone until later,
Well, each of the commands is essentially the same to Geany, substitute some wildcards and execute the command. Maybe a variable list of commands would be worth implementing, with usable defaults.
The submenus for the make custom command could well be postponed.
...
That just leaves the file type specific build and run commands to consider.
The file type dependent behavior is correct for single file type systems where there is no build system.
However consider developing a 'c' extension to python, the compile/build should indeed be dependent on the c file open for editing, but the run command is the python script that imports and tests my c extension, and that command should not be stored against the c file type. This potential conflict exists for any mixed language system. (No I wouldn't remember to switch to the python file before running)
So have user-configurable per-filetype commands, in this case 'Test Python Module' as a C build command.
Also consider the behavior of the build menu item in the presence of a build system, either the menu item does something independent of the build system :-( or it invokes the build system, in which case it should be project dependent not file dependent for all the reasons outlined above.
Geany has to be usable without projects. Some users don't like them and they can get in the way for single files.
... I think broadly I agree with these ideas, thanks for taking the time to look at this. These changes will be quite substantial, I guess they could be done in an SVN branch.
Finally one other suggestion, while looking for where the filetype specific commands are set, I had to look in the code because the menu "set includes and arguments" was not obvious, perhaps it should be changed to "set build & run commands" or something similar.
Yes, something like "Configure Commands".
Regards, Nick