2008/11/14 Enrico Tröger enrico.troeger@uvena.de
On Thu, 13 Nov 2008 19:39:43 +1100, "Lex Trotman" elextr@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@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel