Hi Guys,

I'm now a little confused, I think we have a terminology problem so let me spell out what I mean below.  We can continue to try to sort out the best solution by discussion because I have a sudden family problem and will be away from home and work and unable to code anything for a couple of weeks.  I will be able to continue discussion thanks to gmail being accessible anywhere.  Perhaps we should slow the discussion down to every couple of days so as to not use too much of your time.

I am confused about what we each mean when we are talking about 'build' here, and looking back I am not sure I have been consistent in my usage either.  So I suggest the terminology for this discussion:

1. Filetype commands, menu items labelled:
 - compile,
 - build which I suggest we call build(link) to distinguish it from other meanings of build and
 - execute.

These commands depend on the filetype and and in the new build system will have user configurable menu label and commands stored in the user preferences directory (as is currently done for the commands only).

2. Preference commands, that is the menu items currently labelled 'make something', which I suggest we call make commands to distinguish them from the filetype build command.  These commands will have configurable menu label and command stored in the user preference directory.  These commands can also contain an override for the execute command.

3. Project commands which override preference commands (make commands) when a project is open.  If changed whilst a project is open they will be stored in the project file.  These commands can also contain an override for the execute command.

For most of this discussion on headers I have been talking about filetype commands because both preference and project make commands are independant of the type of file that is open.  Having language specific commands in command sets that are present for all languages is not a nice solution.  And if it is in project files then the user has to configure it again and again for each project.

Although having header compile as an extra filetype command can work, the build(link) menu item can do funny things if invoked on header files.  This is probably fine for an expert like Nick but could be an issue for a beginner just trying things out, thats why I don't like having commands that are not useful available to users.

In the time that I'm away lets see if we can find a solution that doesn't have the problems I've listed above or in previous emails but is simple to implement.  Thanks for your patience we will get there.

Cheers
Lex

2008/11/18 Enrico Tröger <enrico.troeger@uvena.de>
On Mon, 17 Nov 2008 17:14:26 +0000, Nick Treleaven
<nick.treleaven@btinternet.com> wrote:

>Hi,
>
>On Wed, 12 Nov 2008 14:23:47 +1100
>"Lex Trotman" <elextr@gmail.com> wrote:
>
>> 3. Use custom commands, but we still have the two commands problem
>> from the item above and this is something that Geany really should
>> offer its users as standard, not requiring them to configure it.
>>
>> 4. Use project/user preference commands.  Now unwanted commands are
>> visible on all languages which is worse, and we have the same problem
>> that it should be standard.
>
>My thoughts are that for a compile header command, this can be an
>_extra_ build command, so not losing compile, build, etc. As I
>originally said, ideally we wouldn't limit how many commands the user
>can run, it's up to them.

I agree that the ultimate would be to have unlimited commands, but that makes for a more complex configuration GUI and configuration/preference/project file format.  My proposal for now is to add one extra filetype command (compile, build(link), execute and spare) and one extra make command (make all, make custom, make object, execute and spare), remembering all labels and commands can be configured..

>
>So, _if_ compiling a header is a generic command for a filetype, have
>an extra build command configured for the C++ filetype (and C if you
>want).
>

As I said above I am confused about where you are suggesting this command to be added, as a filetype command or as a make command?

>But more likely, compiling a header requires the include arguments for
>library headers, etc, so it would make more sense as an extra project
>command.
>
I'm also confused by this, headers (in my experience) don't need any more include paths than the source file needs ( I guess you are talking about things like Gtk+ and the like that use pkg-config, most other stuff is in the search paths by default for my C++).  So the compile command for headers would have the same includes and agruments as the command for sources.

Compiling headers as a project make command would be great, but I don't know how to set up make and other builders to compile headers (remember that the original reason for my build commands changes was to support different builders)  If there is no output file, what prevents make compiling all the headers every time?  Gcc leaves a .gch file but not all compilers do that (eg Intel C++ for Linux). 

Anyway all I really want is to be able to compile my new or newly modified C++ header file for syntax check purposes.  Once it doesn't inject several hundred syntax errors into the source files that include it I can get on with making them compile and making it actually work using the make commands.  (Yes, the most recent new C++ header file I built had several hundred lines of error messages on first compile (not bad for a file only 370 lines long), This is common because some C++ syntax is really picky and unintuitive (meaning templates) and takes a few tries to get right and C++ headers typically have more in them than C headers.
 

>But either of these can work with a simple build system. The only
>disadvantage I can see is that you would have to remember to use a
>different command from the usual compile/build/whatever you use for
>source files. But I think this is reasonable.

As I said above, for experts it is reasonable but as the filetype commands are probably more used by beginners who havn't got up to speed with make yet, I see having it available as a problem.
 

I fully agree on this. This is basically what I suggested yesterday
(except for that I thought of using a header compile command as one
of filetype commands and not project commands).


Regards,
Enrico

--
Get my GPG key from http://www.uvena.de/pub.asc

_______________________________________________
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel