[Geany-devel] Build system branch 2.0

[Nick Treleaven]

On Fri, 12 Feb 2010 22:59:59 +1100
Lex Trotman <elextr at gmail.com> wrote:

> What I'm arguing is that it isn't possible to sensibly decide what
> limitations to apply without sounding like a dictator, "do it my way or not
> at all".  Let me try to ask some leading questions referring to various
> restrictions in the current system.
> 
> Why do all non-filetype dependent commands have to have their output parsed?
> and so block all other commands?  So now I can't use a pair of tools
>
> together.  What about tools that display output in a GUI, eg viewers, I have
> to close them and lose the output to be able to run another command.
> 
> Same argument for filetype dependent commands of course, but compounded by
> having different tools for different languages, but still if one is running
> no others can.  Even if their is no parsed output to be confused.
> 
> Since any command can be run by the build menu, it can be a long-running
> command, so why not allow a competent user to decide that it is safe to stop
> it if its going wrong?

IMO the solution to all of this is to use Execute commands, not build
commands. Build commands are things that you want geany to monitor
during a build.

> > I think the 'make everything as configurable as possible' idea is one
> > that leads to very complex dialogs, and also IMO is against the design
> > of Geany. There may be other ways.
> 
> Well, I think that making everything configurable stops you having to wire
> logic in the code making it simpler.
> 
> >
> > We could solve the stop issue by having 2 stop commands, one for any
> > build command and one for the execute command (as current).
> >
> 
> Another band-aid (R J&J :-) solution adding more special cases.

No, you're saying add a setting for every possible command, I'm saying,
just add a dialog. You're suggesting more work ;-)

> > Each stop command would prompt 'Killing the process may be unsafe. Are
> > you sure?'.
> 
> Thats a good idea, but better to configure it off so only a user that at
> least understands the question will enable it, rather than asking a question
> of a user who has no idea of the answer.

If the user doesn't understand it, they shouldn't be killing things ;-)

But my point was really that having lots of settings for each command
is one approach to doing this, one I (and I think Enrico) don't like.
There are other ways to add configurability/flexibility which can be
simpler to understand.

> >> > Any increase in functionality needs to have a rationale. Do we need
> >> > each command to be handled individually, or should sets of commands
> >> > have the same behaviour? I prefer the latter.
...
> >> The current SVN version basically works like that and I can't twist it
> >> to support the build commands that I want to use, let alone what other
> >> people may need.  For example Frank & Thomas both have asked for
> >> executes without terminal or parsing. The current SVN can't support
> >> that without one more setting being added and then the next variant
> >> has to be added etc. and soon it gets to where I am at now.
> >
> > Maybe add an execute option for this, I don't think any build commands
> > should need this.
> 
> Why not? See comments above, you are still thinking in terms of a "make"
> type builder whereas it could be anything.  Since the "make" commands can be
> programmed from a project file it makes perfect sense that it may be a web
> CMS or anything else associated with the project.
> 
> >
> > I think it's good to keep build and execute commands separate. They are
> > intended for different things.
> 
> They are only different in the C/C++ workflow, in interpreted languages
> build=execute, in web languages view=execute, if either can execute any
> command how can you separate them?

If you don't want parsing, use execute commands. This can make
understanding the build system easier for the user.

> > This isn't what I meant, though I wasn't clear. I think we should have
> > simple filetype build commands, 'make' commands, execute command(s), and
> > then [a bit] more configurable options for project commands.
> >
> 
> As I said above, this is one particular workflow, no problem if the default
> configuration follows that, but I don't see its good to LIMIT it to that.

I might have forgotten to say: I don't think we should deny users any
features, just that the more advanced things can be done in a way that
doesn't complicate everything else.

Regards,
Nick