[Geany] Generalisation of build system

[Nick Treleaven]

On Fri, 3 Oct 2008 17:32:26 +1000
"Lex Trotman" <elextr at gmail.com> 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