2008/11/17 Enrico Tröger
<enrico.troeger@uvena.de>
On Fri, 14 Nov 2008 12:00:54 +1100, "Lex Trotman" <elextr@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
--
_______________________________________________
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel