Thanks to all for the comments/suggestions so far.
To be sure that I have been clear, when I talk about the Geany build system I am only talking about the ability of Geany to invoke builders, not the system used to build Geany and nor am I talking about incorporating any specific system into Geany nor about incorporating specific support for any system(s) into Geany, just general support for any command that can be run. As Enrico said, simple is better.
Our approach to build tools is that they vary in performance, capabilities and system requirements and individual projects make their decisions based on technical, practical and philosophical grounds. When we then use their pachage we arn't going to change the build system since we would have to re-do it each time a new release happened. So we end up using lots of different systems.
On a specific note, the developer who told me about the -o simply stopped using the facility when he had problems, and so didn't notice it had been fixed. He has been sent to read the release notes 50 times ;-).
Having now had a chance to read the code and talk to my developers some more, I am in a better position to discuss how the system currently works and how we might like it to work.
To ensure I understand it, the current system works as:
1. Compile, build and run are filetype specific and get their command from the filetype config (question what is runcmd2 config for?) 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 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? 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)
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.
In terms of the compile command, it *may* be useful for a quick syntax check but since the user would have to remember what options and symbols need defining, it could be risky, and I certainly would not use the result of such a compile, and the object file would have to be removed so that the builder would re-build the file properly. All in all I see small gain but lots of potential for pain and would agree with Enrico that it may be best to remove the compile command. (however see my second thoughts later)
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 2. each of the four 'make' commands should have its own menu label and complete command string stored in the project file 3. one of the 'make' commands should retain the behavior of asking with a dialog for targets/options to be added to the command stored in the project file
This system has several advantages:
1. it looks relatively simple to implement 2. if can be set up to work exactly as now (well, except for no compile and an extra make) 3. it gains a degree of platform independence, eg 'make object' could have the command 'make %e.o' on unix or 'nmake %e.obj' on windows, and those of us using both targets just have two project files: 'my_proj_win.geany' and 'my_proj_lin.geany' with the appropriate settings. Note it makes the target platform independent of the platform geany is running on, without complicating geany's life. 4. by having variable menu item names we remove the need to remember that, in the 'newt_adventures' project, the 'make all' menu actually means 'jabberwok the gingrich' This is why I think that this is something that goes in the base product not in a plugin, from what I can see plugins can't modify these menus.
Variable numbers of commands and submenus I'd postpone until later, if at all, and agree with Nick that project type templates are plugin territory, anyone out there want to code one.
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)
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.
You will note that the problems develop in a project specific context, so I propose a solution in that context, if a build and run command is present in the project file then that command takes precedence over the filetype specific commands. In fact based on this solution I may even go back on my previous thought and might allow a simple compile command again for syntax check, especially if it didn't actually save its output file or did a lint or similar ;-).
For completeness the "entering directory" string should be made configurable, again just put it in the project file.
The only other code needed would be a tab in the preferences for these project specific commands and settings, but as the tab is fixed layout it should be easy to do with glade.
And then the documentation needs to be updated to explain the operation of the system, it is simple, can have defaults so simple systems work out of the box, but is not obvious without some explanation.
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.
Best Regards Lex