<br><br><div class="gmail_quote">2008/11/17 Enrico Tröger <span dir="ltr"><<a href="mailto:enrico.troeger@uvena.de">enrico.troeger@uvena.de</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, 14 Nov 2008 12:00:54 +1100, "Lex Trotman" <<a href="mailto:elextr@gmail.com">elextr@gmail.com</a>><br>
wrote:<br>
<br>
Hey,<br>
<br>
reading your answer tells me I was too rude in my last mail, this was<br>
not intended.<br>
<div class="Ih2E3d"></div></blockquote><div><br>No offense taken and I hope none caused by my reply. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
<br>
>As I understand it the options you are offering are:<br>
>1. leave is_c_header() in and magically header files have no commands<br>
>available. As I have explained at length before this is a poor<br>
>solution for some users.<br>
<br>
</div>I never wanted to actually suggest that. If I did so, sorry. The reason<br>
why  is_c_header() exists is because I/we thought nobody will ever<br>
compile a header file. Since this assumption seems to be wrong, we<br>
should remove this function.<br>
<div class="Ih2E3d"></div></blockquote><div><br>My misunderstanding, I thought you wanted to keep it, no problem. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
<br>
>2. take is_c_header() out and all the C/C++ language commands are<br>
>available.  Compiling depends on the accident that the command for<br>
>compiling headers is the same as for source.  It is for gcc but not<br>
>for other compilers.  Also 'build' is available and will overwrite the<br>
>file.o from file.cpp with the pre-compiled header from file.hpp. Wrong<br>
>and confusing<br>
<br>
</div>Ok, I didn't know that you actually need special compiler commands.<br>
But one of your goals was to allow setting multiple (up to three, IIRC)<br>
filetype related build commands.<br>
So, an user can set one of those commands to compile header files. And<br>
voila, we are done. But I guess you will tell me that I'm wrong again<br>
and I forgot about anything.<br>
<div class="Ih2E3d"></div></blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
>3. use is_c_header() to allow compile and prevent build and execute,<br>
>again it magically works different to all other filetypes and still<br>
>depends on the command being the same<br>
<br>
</div>Nah, this wouldn't be nice.<br>
<div class="Ih2E3d"><br>
<br>
>As part of the build system changes the distinction between headers and<br>
>source needs to be addressed, which is what we are doing discussing it.<br>
<br>
</div>Yes, that's right and I think 2. is the way to go. If I'm wrong again,<br>
do whatever you like and I won't complain anymore :).</blockquote><div><br>NEVER feel that you can't raise issues or suggestions, I just want to get the best result.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

But please keep in mind to keep the whole stuff simple. Nobody wants to<br>
read 5 paragraphs in the manual just to compile a file.<br>
</blockquote><div><br>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:<br><br>
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)<br>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<br>
3. if there is anything not configurable by GUI then it can go in an appendix for the hard core tinkerers<br><br><br>Cheers<br>Lex<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
<br>
Regards,<br>
Enrico<br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div class="Wj3C7c">Get my GPG key from <a href="http://www.uvena.de/pub.asc" target="_blank">http://www.uvena.de/pub.asc</a><br>
</div></div><br>_______________________________________________<br>
Geany-devel mailing list<br>
<a href="mailto:Geany-devel@uvena.de">Geany-devel@uvena.de</a><br>
<a href="http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel" target="_blank">http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel</a><br>
<br></blockquote></div><br>