[Geany-devel] Committed Project Build Commands to build-system branch

[Nick Treleaven]

On Thu, 6 Nov 2008 21:06:09 +1100
Lex Trotman <elextr at gmail.com> wrote:

> > Cool. I just made some minor commits to fix a warning and refactor
> > some GUI code.
> 
> 
> Ok, warning that this is still a prototype, GUI code is still being
> changed to get the full functionality shown in the geany.txt I
> committed recently.

OK, I'll look at the manual changes hopefully today. The small change
was just for code organization.

BTW, you can commit code that doesn't build, or work-in-progress, no
need to wait until it's ready to test, if you have a lot of changes in
your working copy.

> > BTW there are some formatting issues:
> > 1. Some spaces instead of tabs being used for indentation (e.g. in
> > build.c).
> > 2. Spacing - instead of:
> >
> > if( blah!=foo )some_func( foo );
> >
> > use:
> >
> > if (blah != foo) some_func(foo);
> >
> > Please use the existing code style (see HACKING).
> 
> 
> Do you have a configuration for one of the usual source formatters to
> get the format you want, I AM going to continue to get it wrong
> because it is different to the standard format I use all day every
> day at work. The fingers just automatically put spaces on the other
> side of the ( ) etc. Even if I'm thinking about it, it will get done
> wrong from time to time ;-).  You are correct that it should be
> consistent within Geany so if there is a formatter that will generate
> the format used throughout Geany I will ensure that I use it.

I haven't really tried them, I wrestled with GNU indent once but
couldn't work out how to tell it to use tabs only. Probably there's
a better formatter out there, but you'll have to play with the options
to get a matching style.

> > The indentation is the most important one, could you fix this
> > please?
> >
> 
> Well, all editing has been done in Geany with indentation set to tabs
> so I don't know where the problem came from??? but I can fix it.

Somehow your commit has introduced them, they weren't there before in
build.c (and elsewhere). Try seaching with the regex "^\t*  +" (note the
2 spaces to prevent matches for multiline comments).

There will be a few matches for Glade callback argument alignment, but
other than these all lines should only use tabs.

Sorry to be pedantic ;-)

> > 2. I think we should move the new build_* GeanyProject fields to a
> > GeanyProjectPrivate struct, similar to
> > GeanyDocumentPrivate/GeanyFiletypePrivate. The implementation of
> > those fields might change, so they shouldn't be in the plugin API.
> > I can make this change unless someone disagrees.
> >
> 
> Don't worry, I'll do that because I have already made some changes in
> that area to support the full functionality.  No point in doing it on
> the prototype when there are more changes to come.

OK, cool.

> > > If a project is open the dialog will have extra fields to provide
> > > labels and commands to replace
> > > the "Make" series of menu items on the build menu.
> >
> > (I guess replacing the make menu items is not implemented yet.)
> 
> 
> Did you have a project open? the prototype only adds these items to
> the menu or the build commands dialog when a project is open. The

Yes, I set 2 project build commands, then checked the menu. It doesn't
work after updating the dialog, but reopening the project does work.

BTW there was a bug where the 3rd project build menu item is created
based on the 2nd label.

> full version will also show them for preferences which isn't
> implemented in this version. Coming real soon now though :-) maybe [?]

Not quite sure what you mean, but I'll read the manual changes first.

...
> > Maybe by default they should be set to the default make command
> > labels and commands. Otherwise the dialog is unintuitive - just
> > empty boxes.
> 
> 
> The full version will work that way, see the manual.  Note these are
> generated if there is nothing saved in the project or preferences.
> That way the menu label strings are translated like any string is.
> It is assumed that when a user edits a label they will do it in the
> language they want and so no translation is needed for the label
> saved in project or preferences, but it is important that there is no
> default value saved that isn't translated.

Sounds good.

...
> > > At the moment there is no way to reset project commands to default
> > > without hand editing the
> > > project file.Setting them to blank does just that, it doesn't
> > > reset to default.  A "reset to default"
> > > button will be added.
> >
> > Hmm, why not just use the default if they're blank?
> 
> 
> Because in the full version blank means don't show this menu item,
> this makes the build commands operate the same as the filetype
> commands which do not show unused commands.

OK. Maybe a checkbox to enable them, on by default, might be better.
But no need to implement this.

> NOTE: this brings up one significant change needed for the full
> version, the can compile, can build, flags of the filetype will no
> longer be used since the existance (or not) of such a command is what
> determines if a menu item is shown.  Otherwise users would not be

I agree, I wanted to remove them before.

> able to add filetype commands to unused filetype menu items.  So in
> the full version, a commandwhich is not set will mean use the default
> whilst one set to nothing (item name) will mean don't use. Have to
> allow 'command set to nothing' just in case someone wants to use the
> make custom dialog to type the whole command, possibly useful for
> occasionally used commands whilst still capturing and parsing the
> command output.
> 
> But are there any other important uses of these flags besides
> controlling what is shown in the build menu?

If so, they can be replaced with if (NZV(ft_command_str)) checks (or
maybe just checks against null for the custom command).

Regards,
Nick