On Fri, 3 Oct 2008 17:32:26 +1000 "Lex Trotman" <[EMAIL PROTECTED]> wrote:
> 1. 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. > 2. 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 > 3. %e and %f are substituted in the build command > 4. 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". > 6. 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: > 1. 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: > > 1. 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 _______________________________________________ Geany mailing list [email protected] http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
