[Geany-devel] C/C++ Header filetypes / templates

[Lex Trotman]

2008/11/17 Enrico Tröger <enrico.troeger at uvena.de>

> On Fri, 14 Nov 2008 12:00:54 +1100, "Lex Trotman" <elextr at gmail.com>
> wrote:
>
> Hey,
>
> reading your answer tells me I was too rude in my last mail, this was
> not intended.
>

No offense taken and I hope none caused by my reply.

>
>
> >As I understand it the options you are offering are:
> >1. leave is_c_header() in and magically header files have no commands
> >available. As I have explained at length before this is a poor
> >solution for some users.
>
> I never wanted to actually suggest that. If I did so, sorry. The reason
> why  is_c_header() exists is because I/we thought nobody will ever
> compile a header file. Since this assumption seems to be wrong, we
> should remove this function.
>

My misunderstanding, I thought you wanted to keep it, no problem.

>
>
> >2. take is_c_header() out and all the C/C++ language commands are
> >available.  Compiling depends on the accident that the command for
> >compiling headers is the same as for source.  It is for gcc but not
> >for other compilers.  Also 'build' is available and will overwrite the
> >file.o from file.cpp with the pre-compiled header from file.hpp. Wrong
> >and confusing
>
> Ok, I didn't know that you actually need special compiler commands.
> But one of your goals was to allow setting multiple (up to three, IIRC)
> filetype related build commands.
> So, an user can set one of those commands to compile header files. And
> voila, we are done. But I guess you will tell me that I'm wrong again
> and I forgot about anything.
>

Well its possible, but if there is no distinction between headers and
sources then the user has lost one of the commands for their sources because
they have configured it into a header command. Whilst we could easily add an
extra command, making it simple to implement, and it will work, I still
worry that it isn't a very good one from the users point of view because
even if we add an extra command there is still the problem of other source
commands doing the wrong thing if invoked for headers.  eg the standard
source build command 'g++ -Wall -o "%e" "%f"' if invoked on a header, will
overwrite the executable with a pre-compiled header file with the executable
filename.  Luckily on Linux it is not considered executable so it isn't
dangerous, but it is confusing.

>
>
> >3. use is_c_header() to allow compile and prevent build and execute,
> >again it magically works different to all other filetypes and still
> >depends on the command being the same
>
> Nah, this wouldn't be nice.
>
>
> >As part of the build system changes the distinction between headers and
> >source needs to be addressed, which is what we are doing discussing it.
>
> Yes, that's right and I think 2. is the way to go. If I'm wrong again,
> do whatever you like and I won't complain anymore :).


NEVER feel that you can't raise issues or suggestions, I just want to get
the best result.

But please keep in mind to keep the whole stuff simple. Nobody wants to
> read 5 paragraphs in the manual just to compile a file.
>

This is a good point,my intention is that from a user point of view there
will be little changed, so I will look at re-arranging my changes to the
build-system part of the manual as follows:

1. first a short description of how to use the build system with supplied
defaults without too much reference to details.  This will cover maybe 70%
of the users. (Linux gcc, windows Mingw users I think)
2. then a more detailed description of the system including project building
and configuring the commands via the GUI. Should cover most of the rest of
the users
3. if there is anything not configurable by GUI then it can go in an
appendix for the hard core tinkerers


Cheers
Lex

>
>
>
> Regards,
> Enrico
>
> --
> Get my GPG key from http://www.uvena.de/pub.asc
>
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20081117/d1a84ca7/attachment.html>