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

Fri Nov 14 01:00:54 UTC 2008

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

> On Thu, 13 Nov 2008 19:39:43 +1100, "Lex Trotman" <elextr at gmail.com>
> wrote:
>
> >Hi Guys,
> >
> >Further thoughts on how to allow variations on the commands associated
> >with a filetype, I would propose having a concept of a variant of a
> >filetype. This is just extra information determined from a subset of
> >the filetypes extensions.  It can be implemented fully configurable
> >from the filetypes.xxx file so no hard coded magic.  An extract of the
> >extended filetypes.c below shows what I mean:
> >
> > [...]
> >
> >Attached is a patch against the build-system branch revision 3195
> >which was before header filetypes changes.  It gives you an idea of
> >the amount of code needed to set the variant commands, not too much
> >really and fairly localised.  Obviously saving/restoring and using
> >them is part of the upcoming build system changes so the patch does
> >nothing visible.
>
> Sorry guys,
>
> but it seems we are getting a little off the road.
> The build-system branch has started to improve the build system a
> little, making it more flexible while keeping it almost as simple and
> easy to use as it by now.
> But all this is far away from this. I remember the beginning of this
> whole discussion where I stated my concerns about possible complexity
> introduced by Lex' suggestions. He then answered things will stay easy
> to use but only more flexible. The above don't seem so, sorry.
>
> I don't want to block new things but I really want to keep the build
> system easy to use. I'd be happy to have some super-flexible and
> super-fancy build command things in a plugin which can build every file
> with every option in every possible way at any time or whatever.
>
> But back to topic:
>
> if we remove is_c_header() in build.c, header files can be compiled in
> the same way as any other C/C++ file. So I still don't see why you want
> anything more. At least, any other change is IMO not related to header
> files directly anymore.
> C header files are simple C source files, same syntax, same language.
> Only with different semantics but this doesn't affect the compiler or
> its options. I can compile header files with the same options as source
> files (to some extend, I'm really talking about compiling, not linking).
> Analogous the same is true for C++ headers and source files.
> But we all said this already.
>
> And as far as I understood, your main intention on compiling header
> files is to easily check for compile errors. That way, the current
> Compile command should be enough (of course, with is_c_header() code
> being removed).
>
> Regards,
> Enrico
>

HI,

It is relevant because we are talking about build commands.  They just
happen to be for headers

Enrico I don't like doing a job poorly, incompletely in incorrectly. I feel
you are saying to me, spend the time providing an improved build system but
in the end there will be one part of it that doesn't work and you are not
allowed to fix it :-(.  And it happens to be a part of the most common two
languages!!

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.
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

and there is a half-way house

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

All of these options are poor, incomplete or wrong.

Nick didn't want special case code in the program, but we could find a magic
way of choosing between two sets of commands for C and C++ so it will at
least work correctly from the end user point of view.  It still requires
much of the code and configuration that my last proposal had.

Instead of any special case code, my last proposal provided a general
purpose solution that was configured from the data files.
It required:
1. one extra function,
2. splitting one existing function into two which the build system change
needs to do anyway, and
3. adding members to filetype private structure and document private
structure

for a total of just over 60 lines.  Its impact is cleanly localised and only
adds to existing structures without changing the meaning of the existing
members so it doesn't impact any other code.  There is no user involvement
with the content of the configuration files so it is no harder to use.  This
will be only a small part of the amount of changes build-system will need
and would be part of that change.

I still think that my first solution of separate filetypes is the correct
conceptual solution but I can understand your perceived problems with such a
change so I won't propose it further.

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.
Designing the generalisation of the build system simply brought the issue to
light.

Lex

> --
> 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/20081114/c516d17a/attachment.html>