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